JP6750909B2 - Robot trajectory generation method, robot trajectory generation apparatus, and manufacturing method - Google Patents

Description

The present invention relates to a robot trajectory generation method, a robot trajectory generation apparatus, and a manufacturing method for generating a trajectory for operating a plurality of robot arms arranged and operating in a common work area by a control device.

In recent years, in industrial product production lines and the like, robot devices such as industrial robots have been frequently used for operations such as assembling, processing, carrying, coating, and painting. In this type of production line, in order to improve production capacity and save space, multiple robot devices are placed close to each other, and work is performed simultaneously or in collaboration within a common work area. I have something to do. As described above, when operating a plurality of robot devices in the common work area, it is necessary to control so that interference (contact or collision) does not occur between the robot arms.

To teach robot movements, an operation device called a teaching pendant must be used to input the robot trajectory that changes the position and orientation of the robot arm while confirming by moving the robot device in the actual work environment. There is. In addition, a robot programming method may be used in which a 3D virtual display of the work area of the robot device is displayed on the display device of the robot control terminal, and a trajectory is input while operating the robot device in this virtual environment. In robot teaching using such a virtual environment, input means such as a keyboard, a pointing device, and a touch panel is used to input a teaching point, instead of controlling a robot device in the virtual environment and a teaching pendant.

In the conventional robot teaching (programming) including the above-mentioned teacher's manual operation process, the teacher should consider the route and trajectory of the robot and the timing of operating each robot so that the robots do not interfere with each other. It is necessary to perform teaching work by trial and error. Therefore, in such a conventional method in which the weight of manual operation by the teacher is large, it is difficult to secure a trajectory without interference between the robots as the number of robots and the total number of tasks increase, and a large amount of teaching work is required. There is a problem that it takes time. As a matter of course, when there is a change in the arrangement of peripheral equipment and robots in the production line, the same teaching work must be performed again.

Therefore, in recent years, techniques for automatically generating a path (trajectory) in which a robot does not interfere have been studied. As a method for generating such a route, for example, a route generating algorithm such as RRT (Rapidly exploring Random Tree) or PRM (Probabilistic Road Map Method) is proposed. By using such a trajectory/path generation technique, the instructor only has to specify the start point and the end point of the motion of the robot, so that the burden of the teaching work can be reduced. In addition, since route generation can be executed by computer calculation in a virtual space that simulates the work environment, even if the arrangement of peripheral equipment or robots in the production line changes, a route that does not cause interference in a short time can be created. Can be recalculated.

Further, not only is it possible to generate a path that does not interfere with obstacles in the work environment for one robot, but also if there are a plurality of robots whose position and orientation change momentarily in the work environment, Techniques for generating robot trajectories that do not cause interference between them have also been proposed.

For example, in Patent Document 1 below, interference between robots is avoided by adjusting the timing of starting the operation of the robots. In the interference avoidance method for a plurality of robots of Patent Document 1, the priority order of the operation of each robot is set, and the planned passage area of the robot due to the operation of each robot within a predetermined time, or the occupied area that is an expanded area including the area is set. Calculate sequentially. Then, it is determined whether or not there is an overlap between the calculated occupied areas, and if there is an overlap, one of the robots having the lower priority is placed on standby and the other robot having the higher priority is operated. In addition, the occupied area of the other robot is sequentially released for the portions that have already completed their operations during the operation of the other robot. Then, based on the change in the occupation area of the other robot, the operation of one robot is started after the overlap is eliminated.

Further, in Non-Patent Document 1 below, interference between robots is avoided by adjusting the speed at which the robots operate. In the trajectory generation of Non-Patent Document 1, the route from the start point to the end point of each robot is calculated assuming that no other robot exists, and then a graph with the position of each robot on the route as a parameter is generated. Then, the combination of the positions on the path of each robot that does not interfere with each other is searched for on the generated graph, and the combination of the initially found path and the position on the path of each robot is combined to operate while adjusting the speed. We have orbits that do not interfere with each other.

JP-A-8-166809

G. Sanchez and J.-C. Latombe, "On delaying collision checking in PRM planning: Application to multi-robot coordination" International Journal of Robotics Research, vol. 21, no. 1, pp. 5-26, 2002

The trajectory control described in Patent Document 1 and Non-Patent Document 1 is premised on synchronous control. For example, in any trajectory control, after determining the route/trajectory of each robot, synchronously controlling and adjusting the timing of each robot's operation and the speed of each robot's operation, the trajectory without interference between robots To generate.

However, even if the conventional trajectory control as described above is performed, the passage area of the robot at a certain time may intersect with the passage area of another robot at another time. That is, in the above-mentioned conventional technology, since the robots are controlled so that they do not interfere with each other on the time axis, in a real environment, if there is a deviation in the operation speed or the operation timing of the robots, the robot arms will not move. Interference may occur. For example, if one of multiple robots is abnormally stopped on a common passage area, or if the actual motion speed of the robot is far from the ideal speed, the robots may interfere with each other. There is.

Further, the above-mentioned conventional trajectory control is a technique for controlling so that a plurality of robots do not occupy the same space at a specific time, and it is necessary to perform calculations related to both the space axis and the time axis. There is a possibility that the calculation load of is large and requires a large amount of calculation resources.

In view of the above problems, an object of the present invention is to ensure that, in the generation of a robot trajectory, the passage areas of a plurality of robot arms may cross each other without fail regardless of the operating speed of the robot arms in the real environment and the accuracy of timing control. Is to be able to be significantly reduced. Another object of the present invention is to enable a low-speed control device to generate a trajectory at high speed.

In order to solve the above-mentioned problems, the present invention provides a robot trajectory generation method in a controller that generates a trajectory of a robot arm, wherein the controller passes a body of a first robot arm based on trajectory definition data. A storage step of storing space data in a memory, the space corresponding to the space that should be avoided by the second robot arm; and the controller while avoiding the space corresponding to the space data. a generating step of generating a trajectory 2 of the robot arm is operated, the possess, after generating the spatial data, if it can not generate a new trajectory that avoids space corresponding to the space data, the spatial data Adopted a clear configuration.

According to the above configuration, in the generation of the robot trajectory, it is possible to significantly reduce the possibility that the passing regions of the plurality of robot arms may cross each other reliably regardless of the operation speed of the robot arm in the real environment and the accuracy of the timing control. it can. Further, according to the above configuration, since calculation and control related to the time axis are not used for avoiding obstacles of the robot arm, high-speed trajectory generation is possible even when a low-speed control device is used.

It is explanatory drawing which showed the structure of the robot trajectory generation system which can implement this invention. 3 is a block diagram showing a configuration of a control system of the trajectory generation device according to the first embodiment. FIG. It is a flowchart figure which showed the outline of the flow of the orbital generation control of Examples 1-3. FIG. 5 is an explanatory diagram showing two robot arms according to the first embodiment. 6 is a flowchart showing a flow of trajectory generation control according to the first embodiment. FIG. (A)-(c) is explanatory drawing which showed the trajectories of the two robot arms which concerns on Example 1, and its passage area. FIG. 9 is a flowchart showing a flow of trajectory generation control according to the second embodiment. (A)-(d) is explanatory drawing which showed the trajectories of the two robot arms which concern on Example 2, and its passage area. (A)-(d) is explanatory drawing which showed the trajectories of the two robot arms which concern on Example 2, and its passage area. FIG. 8 is a diagram showing timings of two robot arm operations according to the second embodiment. (A)-(f) is explanatory drawing which showed the trajectories of the two robot arms which concern on Example 3, and its passage area. FIG. 10 is a diagram showing timings of two robot arm operations according to the third embodiment. FIG. 9 is a flowchart showing a flow of trajectory generation control according to the third embodiment. It is explanatory drawing of the user interface for operation command input which can be implemented in the robot trajectory generation system of FIG. (A)-(c) is explanatory drawing which showed the transition of the data content in the obstacle memory in Example 1. (A)-(f) is explanatory drawing which showed the transition of the data content in the obstacle memory in Example 2. FIG. (A)-(f) is explanatory drawing which showed the transition of the data content in the obstacle memory in Example 3. FIG. It is a flowchart figure which showed the control example of the principal part of the trajectory generation control which concerns on Examples 1-3.

Embodiments for carrying out the present invention will be described below with reference to the embodiments shown in the accompanying drawings. It should be noted that the following embodiments are merely examples, and for example, the detailed configuration can be appropriately changed by those skilled in the art without departing from the spirit of the present invention. The numerical values taken in the following embodiments are reference numerical values and do not limit the present invention.

The "robot" referred to in the present specification may have any configuration as long as it is operated and controlled by a power source such as a motor, and the present invention is limited by its basic configuration. It is not something that will be done. In the following embodiments, a trajectory generating method and a trajectory generating apparatus for a robot according to the present invention will be described by taking a vertical serial link type multi-joint robot arm having a rotary joint as an example. However, the present invention can be implemented, for example, even when a plurality of articulated robots on the parallel link side, robots that move on a plane, and the like are arranged in a work environment to generate their trajectories.

<Example 1>
1 and 2 show the configuration of a robot trajectory generation system according to a first embodiment of the present invention. FIG. 1 shows the configuration of the entire robot trajectory generation system. In FIG. 1, for example, the arithmetic processing unit 1 can be configured using hardware such as a PC (personal computer). A keyboard 11 and a mouse 12 (or a pointing device such as a trackpad) are connected to the arithmetic processing unit 1 as input units for an operator (robot teacher) to input an operation command. Further, a display 13 is connected as a display device for confirming an operation command input by an operator and a robot trajectory generated based on the operation command.

The external storage device 14 and the network interface 31 can be connected to the arithmetic processing unit 1. The external storage device 14 of FIG. 1 is mainly configured by an external disk device such as an HDD or SSD, or various optical disk devices. The network interface 31 is used to transfer operation command data and the like to an actual robot arm.

Further, the external storage device 14 and the network interface 31 can be used as an install/update unit for installing a robot trajectory generation program, which will be described later, in the arithmetic processing unit 1 or updating the installed program. In that case, for example, the external storage device 14 can be configured by an optical disk device capable of exchanging media. The control program for implementing the present invention can be installed in the arithmetic processing unit 1 via the above-mentioned optical disk, and can be updated. Similarly, the control program for implementing the present invention can be installed in the arithmetic processing unit 1 via the network interface 31 using a predetermined network protocol, and can be updated.

In the robot trajectory generation device of FIG. 1, for example, trajectory generation is performed for a plurality of (two in this case) robot arms 5 and 6 arranged in the same work environment. In the working environment of the robot arms 5 and 6, there are cases where an obstacle 7 that should avoid interference or collision with the robot arms 5 and 6 is arranged. The obstacle 7 is any object placed in the work environment other than the robot arms 5 and 6, such as another component supply device, a ventilation duct, or a housing of the arithmetic processing unit 1. In the trajectory generation control described later, the robot trajectory is generated so that the robot arms 5 and 6 do not interfere with the obstacle 7 and the robot arms 5 and 6 do not interfere with each other.

An operator (robot administrator, robot programmer, etc.) inputs a motion command for the robot arms 5 and 6 via the user interface displayed on the display 13 using the keyboard 11, the mouse 12, etc. (trajectory). Definition data input). The user interface configured by the graphic display on the display 13 includes, for example, a dialog display as shown in FIG. 14 described later, or a GUI by the 3D virtual display described below. In the operation command input of the present embodiment, the operator inputs the trajectory definition data including, for example, the starting point and the ending point (three-dimensional coordinates) of the trajectory to be generated.

The arithmetic processing unit 1 generates an operation command list including trajectory definition data based on the input operation command, and generates a trajectory of the robot arms 5 and 6 based on this operation command list.

The robot trajectory generation device in FIG. 1 may be connected to an actual robot arm that is the target of trajectory generation, and can generate a robot trajectory even in an offline environment where there is no connection with the robot arm. Is configured as follows. In the robot trajectory generation in the off-line environment, the display 13 displays 3D virtual images of the robot arms 5 and 6 to be programmed. Such a 3D virtual display GUI can be configured so that the arm and its joints virtually displayed on the display 13 can be operated using the keyboard 11, the mouse 12, and the like.

By using such a virtual environment, the start point and the end point of the robot trajectory can be displayed by operating the robot arms 5 and 6 that are virtually displayed, in addition to the dialog display described later (for example, FIG. 14 described later). (Position, posture) can be input. Further, according to such a virtual environment, it is possible to perform an operation such as changing the arrangement of the robot arm or the obstacle in the virtual space, if necessary.

FIG. 2 is a block diagram showing an example of the configuration of the control system of the arithmetic processing unit 1. In the configuration shown in the figure, each unit such as the CPU 20, the ROM 21, the RAM 22, the HDD 23 (for example, one built in the casing of the arithmetic processing unit 1) is connected to the system bus 29.

The external storage device 14 of FIG. 1 is connected to a system bus 29 via an interface 28. In FIG. 1, an optical disk device is illustrated as a member that particularly constitutes the external storage device 14, but such a disk device is shown as a recording disk drive 24 in FIG. 2. The recording disk drive 24 can read data from the recording disk 15 configured in various formats such as optical disks, or write data to the recording disk 15. Therefore, the recording disk 15 can be used, for example, for inputting and outputting a control program for implementing the present invention. In that case, the recording disk 15 constitutes a computer-readable recording medium of the control program.

The keyboard 11, mouse 12, and display 13 of FIG. 1 are connected to the system bus 29 via interfaces 25, 26, and 27, respectively. Further, the network interface 31 controls communication between the external network 32 and the system bus 29. For this communication, TCP/IP or various communication protocols executed on it can be used.

The trajectory generation program described below can be executed, for example, on the OS operating in the arithmetic processing unit 1. Depending on the configuration of this OS (operating system), a virtual storage unit that uses a storage area such as the HDD 23 can be used. In that case, an area such as an obstacle memory to be described later may be secured not only on a main storage device such as a RAM but also on such a virtual storage unit (by the HDD 23 or the like).

FIG. 4 shows a schematic configuration of a work environment including the robot arms 5 and 6 which are the trajectory generation targets of this embodiment and the obstacle 7. Here, in order to facilitate the description, a very simplified configuration is shown as the configuration of the robot arm. For example, the robot arms 5 and 6 in FIG. 4 are three-joint robot arms. In the following, for convenience of explanation of control, the robot arms 5 and 6 may be referred to by alphabets A and B, respectively.

The robot arm 5 includes three links 55, 56, 57 and joint shafts 51, 52, 53 connecting them, and an end effector 54 such as a robot hand is provided at the tip of the link 57. .. The robot arm 6 also includes links 65, 66 and 67, joint shafts 61, 62 and 63, and an end effector 64. The three joint axes of each robot arm 5 and 6 have a rotation drive mechanism, and the position of the end effectors 54 and 64 located at the tip of the robot arm 5 and 6 is determined by the angle of rotation.

The rotary drive mechanism for the joint shaft of each robot arm 5 and 6 is provided with a drive system such as a servo motor and a speed reducer (not shown), and can be controlled to a rotation angle based on the robot control data. For the end effectors 54 and 64 such as robot hands, for example, control conditions such as the opening degree of fingers can be controlled via the same drive system such as a servo motor and a speed reducer. With such a configuration, by transmitting the robot control data to each of the robot arms 5 and 6, it is possible to control each arm to a specific position and orientation and to make the end effectors 54 and 64 perform a specific operation. Although a drive source such as a servo motor has been illustrated above, joints and end effectors do not necessarily have to be electrically driven and controlled. For example, the joints and end effectors of the robot arms 5 and 6 may be driven by pneumatic pressure controlled by robot control data, pneumatic pressure or hydraulic pressure of a hydraulic actuator.

As shown in FIG. 4, the robot arm 5 and the robot arm 6 are arranged close to each other in the work environment, and the obstacle 7 exists in the work environment. Therefore, depending on the angles of the joint axes of the two robot arms, interference may occur between the links and joint axes of the robot arms and the end effector. In the trajectory generation control described below, the robot trajectory is generated so that the robot arms 5 and 6 do not interfere with each other. In that case, of course, a robot trajectory is generated so that the robot arms 5 and 6 do not interfere with the obstacle 7.

Hereinafter, with reference to FIG. 3, FIG. 5, FIG. 6, FIG. 14, and FIG. 15, a method for generating a robot trajectory according to the present embodiment, in particular, a method for generating a robot trajectory so that passage areas of a plurality of robots do not intersect each other will be described. explain.

FIG. 3 shows the overall flow of the robot trajectory generation control, and FIG. 5 shows the control procedure for generating the robot trajectory so that the passage areas of the plurality of robots of this embodiment do not intersect each other. FIGS. 6A to 6C show how the trajectory is generated based on the style of FIG. Further, FIG. 14 shows a dialog displayed on the display 13 for inputting an operation command, and FIGS. 15A to 15C show transition of data contents in the obstacle memory in the first embodiment.

In step S100 of FIG. 3, the operator inputs an operation command for the robot arms 5 and 6 via the user interface displayed on the display 13 using the keyboard 11, the mouse 12, and the like. For example, a dialog 131 as shown in FIG. 14 is displayed on the display 13, and the operator is prompted to input an operation command through this dialog.

A title bar 1311 including, for example, a title display (“input operation command” in this example) is displayed at the top of the dialog 131 in FIG. The dialog 131 is divided into a section 1315 for inputting for the robot arm 5(A) and a section 1316 for inputting for the robot arm 6(B).

The upper part of each of the sections 1315 and 1316 is an input section in which each row is associated with one record corresponding to one operation command, and is divided into input fields 1321 to 1324, for example. A field 1321 is a field of the name of the operation command in question, and the name of the operation command may be input to the operator in this field, and the name of this operation command is automatically and sequentially generated by the CPU 20. You may. In this example, operation commands Ma1, Ma2, Ma3 are input on the robot arm 5(A) side, and operation commands Mb1, Mb2 are input on the robot arm 5(B) side.

In the present embodiment, as the motion command, as the trajectory definition data, the data of the start point and the end point of the trajectory corresponding to the motion command are input. The start point and the end point are three-dimensional (XYZ) coordinates for moving the reference part of each arm which is set at the tip of the robot arms 5 and 6, for example, around the bases of the end effectors 54 and 64.

The data of the starting point and the ending point of these trajectories are input to fields 1322 and 1323, respectively. In FIG. 14, Sa1 and Ga1, Sa2 and Ga2, Sa3 and Ga3 are input as start point and end point data corresponding to the operation commands Ma1, Ma2, Ma3 of the robot arm 5(a). Further, Sb1 and Gb1 and Sb2 and Gb2 are input as start point and end point data corresponding to the operation commands Mb1 and Mb2 of the robot arm 6(b).

Here, the character string representations such as Sa1, Ga1... Are shown in each field of the start point and end point data, but in practice, the numerical data representation such as three-dimensional coordinate data is used. You can In that case, the numerical values of the start point and end point data may be manually input from the keyboard 11 or the like, or may be determined by operating the robot arms 5 and 6 in virtual display. For example, the operator points the space in the virtual display of the display 13 with the mouse 12 and inputs the coordinates of the desired reference portion of the arm. Alternatively, the robot arms 5 and 6 that are virtually displayed on the display 13 are operated by the mouse 12 or the like so that the position and posture corresponding to the coordinates of the reference portion of the desired arm are taken, and the reference portion of the reference portion is displayed using a dialog (not shown). The coordinates may be fixed. In either case, numerical data corresponding to the determined coordinates of the reference part are input and displayed in the fields 1322 and 1323 as start point and end point data.

Further, a field 1324 is arranged in each of the sections 1315 and 1316 corresponding to the robot arms 5 and 6 so that an operation command corresponding to the immediately previous operation can be designated. The field 1324 is used to specify an operation command immediately before the operation command (for example, referred to by the name of the field 1321). By providing this field 1324, the sections 1315 and 1316 corresponding to the robot arms 5 and 6 have a structure like a linked list in which the relationship before and after each operation command is related. As shown in FIG. 14, in the user interface, by arranging an input means such as a field 1324 that can relate the front-back relationship of the operation command, the operator performs an operation such as exchanging before and after the input operation command. Can be done.

Actually, when an operation command is input as shown in FIG. 14, the CPU 20 stores the operation command data corresponding to the input operation command as an operation command list in the main memory or virtual memory managed by the CPU 20. Therefore, although FIG. 14 may be considered as a screen display of the user interface, it may be considered as a memory map corresponding to the configuration of the operation command list in the main memory or virtual memory of the arithmetic processing unit 1. In that case, the operation command data is stored in the operation command list on the main memory or the virtual memory in a storage format such as a linked list, and the context of each operation command is related by the pointer data similar to the above field 1324. Be attached.

Below the sections 1315 and 1316, buttons 1317 and 1317 operated by the mouse 12 or the like are arranged in order to determine the trajectory definition of each arm (A, B) input at the upper portion thereof.

In step S100 of FIG. 3, the operator inputs a desired operation command to each of the robot arms 5 and 6 (A, B) using the above-described user interface, for example. In response to this, the CPU 20 generates the data structure of the operation command list corresponding to the input of the operation command in the main memory or the virtual memory.

In step S101 of FIG. 3, priority setting is performed to determine the order of motion trajectory generation. The priority may be, for example, the priority of each robot arm, which of the robot arms 5 and 6 (A, B) is to be prioritized. Further, a priority may be considered in which the trajectory definition data of the operation commands Ma1, Ma2, Ma3..., Mb1, Mb2... In this way, by enabling some priority settings (in different units), it is possible to obtain a suitable control result according to the characteristics of the operation desired to be executed by the robot arms 5 and 6 (A, B). Becomes higher. A control example relating to the priority in units of the robot arm or the operation command will be described later with reference to FIG.

In step S102 of FIG. 3, the robot arms 5(A) to 6(B) are operated based on the start point and end point data which is one trajectory definition data in the motion command list in the order according to the priority determined in step S101. ) Generate one orbit. In this case, the CPU 20 calculates the trajectory from the start point to the end point so as to avoid the obstacle (the space thereof) registered in the obstacle memory, as described later. For the calculation of the trajectory from the start point to the end point, a known trajectory generation algorithm such as the above-mentioned RRT and RPM can be used.

In step S103, when the robot arm 5(A) or 6(B) is operated on the trajectory generated in step S102, the space in which the body of the robot arm sweeps (passes) is set to another robot arm. Is registered in the obstacle memory as an obstacle that cannot enter. Actually, steps S102 and S103 of FIG. 3 are processed one by one by a loop as shown in FIG. 5 described later. Thereby, the trajectory is generated based on all the trajectory definition data (start point and end point data) in the operation command list.

In the examples of FIGS. 4 and 6, only the movements of the respective robot arms 5(A) and 6(B) within the plane shown are shown. However, when the robot arm is actually operated in a three-dimensional work area, the space in which the body of the robot arm sweeps (passes) while changing its posture is a space having a specific shape and volume. The space in which the body of the robot arm sweeps (passes) is sometimes called a sweep volume (Sweep (Swept) Volume). Therefore, in the examples of FIGS. 6A to 6C, the space in which the skeleton of the robot arm is swept (passes) when the robot arm operates on a certain trajectory is indicated by a reference symbol such as SVa.

FIGS. 6A to 6C show how the trajectory is generated corresponding to the operation commands Ma and Mb of the robot arms 5(A) and 6(B). Here, the (start point, end point) of the trajectory corresponding to the operation command Ma is (Sa, Ga), and the (start point, end point) of the trajectory corresponding to the operation command Mb is (Sb, Gb), as shown in FIG. It is located in. Trajectories generated by the trajectory calculation of the CPU 20 based on the operation commands Ma and Mb are indicated by Tra and Trb.

In the example of FIG. 6, it is assumed that the trajectory of the robot arm 5(A) is first generated according to the set priority. Here, the trajectory Tra of the robot arm 5(A) is generated in the shape as shown in order to avoid the obstacle 7 already registered in the obstacle memory. The sweep region swept by the body of the robot arm 5(A) by the robot motion of this generation trajectory is SVa. The space of SVa is a space having a shape and (volume) according to the shape and posture of the body of the robot arm 5(A), the trajectory Tra, and the like.

In this embodiment, when the trajectory of one robot arm is generated, the sweep space SV is registered in the obstacle memory (similar to the obstacle 7). FIGS. 15A to 15C show how obstacles (SVx) are registered in the obstacle memory 2201 in accordance with the trajectory generation in FIGS. 6A to 6C.

The obstacle memory 2201 shown in FIGS. 15A to 15C is secured in the main memory managed by the CPU 20, such as the RAM 22, and is generally composed of two fields 2203 and 2204. In FIG. 15, the reference numeral “22” corresponding to the RAM 22 is used as the storage destination of the obstacle memory 2201 for the entire storage area. However, this is for convenience only, and the obstacle memory 2201 is secured in the main memory or virtual memory (for example, the RAM 22 or further the HDD 23) managed by the CPU 20 as in the case of the operation command list described above. You may This also applies to FIGS. 16 and 17 described later.

Field 2203 of the obstacle memory 2201 stores obstacle identification data (name, identification number, etc.). Further, in the field 2204, shape data (substantial data thereof, or pointer data to a storage space (not shown) secured separately) that defines the three-dimensional space of the obstacle is stored.

The format of the shape data of the field 2204 is arbitrary. For example, consider the work space as a set of unit voxels. In that case, the shape data of the obstacle stored in the obstacle memory 2201 may be a pointer list to the coordinate data of the voxel occupied by the obstacle in a simple example. As a data format that can be easily used for reference, a three-dimensional voxel data table (not shown) may be secured in the main memory or virtual memory in the voxel space corresponding to the work space. Then, an obstacle flag (or identification data of the robot that generated the obstacle by the body sweep) is arranged in the memory cell corresponding to the voxel occupied by the obstacle in this voxel data table. By using the voxel data table together, it is possible to realize an obstacle memory that can easily refer to whether a specific coordinate in the work space is included in the obstacle area.

In the case of FIGS. 6 and 15, first, the trajectory Tra of the robot arm 5(A) is generated as shown in FIG. 6(b) so as to avoid the obstacle 7. Prior to this processing, the shape data of the obstacle 7 has already been registered in the fields 2203 and 2204 as shown in FIG.

When the trajectory Tra of the robot arm 5(A) is generated as shown in FIG. 6(b), the data of the sweep space (SVa) is additionally registered in the obstacle memory 2201 as shown in FIG. 15(b). .. In this case, by referring to the identification data of the field 2203 (name such as SVa in the example in the figure), the identification of the robot that has generated the obstacle by the corresponding body sweep can be identified.

Then, for the robot arm 6 (B), a trajectory (Trb in FIG. 6C) is generated from the start point and end point data of (Sb, Gb). At this time, referring to the contents of the obstacle memory 2201, the obstacle corresponding to the sweep space (SVa) of the robot arm 5(A) is already registered in the obstacle memory 2201 (FIG. 15(b)). Therefore, as shown in FIG. 6C, the CPU 20 determines the robot arm 6 (B) from the start point and end point data (Sb, Gb) so as to avoid the sweep space (SVa) of the robot arm 5 (A). Generate a trajectory Trb.

The space (SVb) swept by the body of the robot arm 6(B) is additionally registered in the obstacle memory 2201 by the generation of the trajectory Trb of the robot arm 6(B). FIG. 15C shows a state of the obstacle memory 2201 immediately after the sweep space (SVb) of the robot arm 6(B) corresponding to the trajectory Trb is additionally registered.

As described above, by the trajectory generation and the obstacle memory management which are schematically described with reference to FIGS. 3 to 6, 14 and 15, the robot arms 5 and 6 do not interfere with each other, and the working environment is reduced. It is possible to generate a trajectory that does not interfere with the obstacle 7 inside.

In this embodiment, the time axis and control timing are not used as the obstacle avoidance strategy. In the present embodiment, the space swept by the robot arm body in a specific trajectory is registered in the obstacle memory 2201 as an obstacle space that the robot arm may occupy. Therefore, it is possible to generate a trajectory in which the robot arms or the robot arms and other obstacles do not interfere with each other with certainty even when there is a timing shift such as a delay in robot operation in the actual machine environment. That is, according to this embodiment, it is possible to generate a more fail-safe robot trajectory.

Here, a more detailed control example of the robot trajectory generation and the obstacle additional registration processing shown in steps S102 and S103 of FIG. 3 is shown in FIG.

FIG. 5 shows an example of a control procedure of the present embodiment for generating trajectories in which the passage areas of the robot do not intersect each other. As described with reference to FIG. 3, the flow of the entire control procedure starts with the input of the operation command, the generation of the operation command list (S101), and the priority setting (S102). After that, trajectory generation (S103) and obstacle addition (S104) are performed. FIG. 5 shows an example of a more detailed configuration of this control procedure.

FIG. 5 includes the following control process. That is, an operation command list including the start point and the end point of the trajectory of the plurality of robot arms is generated (trajectory definition data generation step: S200). The order in which each trajectory is generated is determined based on the operation command list (generation order determination step: S210). For a specific robot arm in the motion command list, trajectory generation is performed based on the start point and the end point so as to avoid the obstacle space registered in the obstacle memory for trajectory generation of another robot arm (trajectory generation step: S230). ). When the robot arm is operated on the generation trajectory, a sweep space swept by the body of the arm is added to the obstacle memory as an obstacle space to be avoided by another robot arm (obstacle registration step: S240, S250).

In FIG. 5, the operation command input and the operation command list generation (S101) in FIG. 3 correspond to step S200, and the priority setting (S102) corresponds to step S210. Step S220 corresponds to the initialization process of the loop of steps S230 to S250. Further, the trajectory generation (S103) and the obstacle addition (S104) in FIG. 3 correspond to step S230 and step S250, respectively. Step S260 is a control step for executing each process of steps S230 to S250 for the trajectory definition data (start point, end point) included in the operation command list.

In step S200 of FIG. 5, the operator (teacher) inputs an operation command for generating a trajectory for all the robot arms via the user interface as described in FIG. Here, for example, it is assumed that one operation command Ma1 for the robot arm 5 is given by the trajectory definition data of the start point and the end point (Sa, Ga). For the robot arm 6, one motion command Mb1 is given as the trajectory definition data motion command Op1 of the start point and the end point (Sb, Gb).

This motion command refers to a set of a plurality of motions designated for each robot arm, and the motion command data is stored in the main memory or virtual memory managed by the CPU 20 as a motion command list as described above. It

The motion (M) is defined by trajectory definition data including a combination of coordinates of a start point and an end point of a reference part corresponding to the base of the end effector (54, 64) of the robot arm (5, 6).

When there are a plurality of postures of the robot arm (5, 6) with respect to the position of the end effector (54, 64) like a multi-joint robot, a combination of angles of each joint is designated as a start point or an end point.

The operation command Op1 given as described above is
Op1={Ma1, Mb1}
And each operation (Ma1, Mb1) is Ma1=(Sa, Ga), Mb1=(Sb, Gb)
Consists of.

Next, in step S210 of FIG. 5, the trajectory generation order is determined, that is, the order in which the trajectory of the motion is to be generated is determined from the motion command list. Various methods can be considered because the method of determining the order affects the operation time of the entire robot.

An example of the priority control will be described in detail later, but here it is assumed that the operator sets the operation priority of the robot arm 5(A) higher than that of the robot arm 6(B). .. Actually, it is not rare that there is a difference in the importance of the operations performed by each robot arm, and it is necessary to allow the user (worker) to set the priority for each robot arm. Then, more realistic trajectory generation becomes possible.

If the robot arm 5(A) is set to have a higher motion priority than the robot arm 6(B), the motion command Ma1 of the robot arm 5 is first generated to generate the trajectory, and the robot arm 6 is moved. The operation command Mb1 of 1 is controlled to generate a trajectory later. In addition, since the control relating to the time axis is not performed in the trajectory generation and the obstacle registration of the present embodiment, the movement (M) in the movement command list is shuffled in a specific priority order regardless of the input order. Orbit generation (and obstacle registration) may be performed. The process of step S210 is realized by a process of securing a table memory or the like storing the generation order and storing the pointer data or the like pointing to the operation (M) in the operation data command list in the above priority order.

In the loop control of FIG. 5, the trajectory generation (obstacle registration) order is controlled by a pointer (or counter) i. Here, i=0 corresponds to the priority of the highest-priority processing, and i is incremented and referred to as 0, 1, 2,... However, it is assumed that the priority sequentially decreases thereafter. Therefore, in step S220 of FIG. 5, the pointer (or counter) i of the rank is initialized to i=0.

After that, the trajectory generation of the motion command Mi (S230: robot trajectory generation process), the generation (S240) of the passage (sweep) region of the robot arm corresponding to the motion command Mi, and the additional registration of the passage (sweep) region (S250: obstacle) Repeat the registration process). This control loop continues until it is determined in step S260 that all motion commands have been processed. While all the operation commands are not processed, the control loops from step S260 to step S230 while incrementing the pointer (or counter) i (i=i+1).

In step S230, a trajectory for one motion of the robot is generated. This step S230 can be executed in three steps such as a route planning process, a route shortening process, and a trajectory calculation process.

Of these, in the route planning process, a route that avoids obstacles from the start point to the end point is obtained. In order to obtain the route, it is possible to use a method in which the CPU 20 automatically calculates by random search by various known methods such as the above-mentioned RRT and PRM.

Next, in the route shortening process, the route generated by the route planning process can be corrected. When the method using random search is selected in the route planning process, the generated route may be a detour or the angle change may be abrupt, so it is necessary to correct the route. In this route shortening process, there are many ways to shorten the route, such as searching for points that can connect without interference between points in the route and smoothing the route by approximating with a spline curve. Any method may be used.

Further, in the route planning process and the route shortening process, a process is performed in the 3D virtual space to confirm whether or not there is interference between the robot arms (5, 6) and the obstacle (7). Here, the shape data of the robot arm (5, 6) and the obstacle data (SV) held in the obstacle memory 2201 can be handled as a set of the above-mentioned voxels (or polygons), for example. Then, it is determined whether or not there is an interference state between the robot arms (5, 6) and the obstacle (7) by determining whether or not the set of voxels (polygons) geometrically contact each other.

The obstacle memory 2201 stores an arm passage (sweep) area associated with trajectory generation as obstacle data (SV), but generally (obviously) the arm passage (sweep). The obstacle data (SV) generated by does not have to be avoided. For example, in the trajectory (path) generation of the motion (Ma) of the robot arm 5 (A) in the above configuration, the obstacle (SVb) generated by the passage (sweep) by the motion (Mb) of the robot arm 5 (B). To avoid. However, in the trajectory (path) generation of the motion (Ma) of the robot arm 5(A), the obstacle (SVa) generated by the passage (sweep) by the motion (Ma) of the robot arm 5(A) is avoided. No need.

In the trajectory calculation process of step S240, the rotational speed and acceleration of each joint of the robot arm (5, 6) are set so that the route (trajectory) generated by the route planning/path shortening process can be operated in the shortest time. To calculate. However, in this trajectory calculation process, the rotational speed and acceleration of each joint are calculated within the range that does not exceed the constraint conditions held in the storage unit 3. However, in the trajectory calculation of the present embodiment, since the fail-safe obstacle avoidance condition is used, it is not necessary to consider the synchronization between the robot arms, and it is possible to calculate a trajectory that allows a single robot to operate in the shortest time. Good.

The trajectory data group (control data of the robot arm) generated by the trajectory calculation process is stored in the main memory or virtual memory, or in a storage area of the trajectory data (not shown) secured in the HDD 23 or the like.

In step S240, a region (space) through which the skeleton (link or joint axis) of the robot arm passes (sweep) when it is operated on the trajectory obtained in step S240 is calculated. Geometry data such as the shape and size of each robot arm (5, 6) is prepared in advance in the HDD 23, the ROM 21, etc., and the CPU 20 calculates the above-mentioned passage (sweep) area (space) based on this geometry. can do. In the actual calculation, a known Swept Volume generation method for obtaining a region through which various moving objects have passed, a technique for approximating the passing region into a simple shape such as a cube or a sphere, and the like can be used. Further, the shape data may be expressed as a set of polygons and used for the interference confirmation processing. The geometry data such as the shape and size of the robot arm (5, 6) can also be used for controlling the virtual display on the display 13.

In the example of FIG. 6B, when the trajectory Tra is generated with respect to the robot arm 5, the CPU 20 calculates the passing (sweep) area to cause the body to pass from the start point Sa to the end point Ga. , A passage (sweep) area (SVa) in the figure is generated.

Then, in step S250, the passing (sweep) area (SV) generated based on the trajectory generation in step S230 is registered in the obstacle memory 2201. The obstacle registered in the obstacle memory 2201 is added to the area as a new obstacle in the virtual space, and in the subsequent trajectory generation of the robot arm (6), all obstacle data in the obstacle memory 2201 is avoided. The orbit calculation is performed.

In the example of FIG. 6, after the trajectory generation of the operation command Ma1 of the robot arm 5 and the addition of the obstacle in the passage area are completed, the trajectory generation of the operation instruction Mb1 of the robot arm 6 (and the addition of the obstacle in the passage area) is performed. .. The flow of processing is the same as that described above, but when the trajectory of the operation command Mb1 of the robot arm 6 is generated, the passage area SVa is added as a new obstacle (FIG. 15(b)). Therefore, the trajectory generation of the motion command Mb1 is performed so as to avoid not only the obstacle 7 which is arranged in advance as shown in FIG. 6C, but also the passing area SVa of the trajectory Tra of the motion command Ma1. It

In this way, with respect to the robot arm 6, a trajectory Trb that does not intersect the trajectory Tra of the robot arm 5 can be obtained. In the above description, the simplest example in which the trajectory is generated with the robot arm 5->6 is shown, but the passage (sweep) area corresponding to the trajectory Trb of the robot arm 6 is also stored in the obstacle memory 2201 as a new obstacle. to add. Thereby, the trajectory generation (without causing the interference state) can be continued based on the subsequent operation command.

In the above description, the simplest example of two robot arms has been described. However, for trajectory generation of three or more robot arms, trajectory generation and obstacle registration accompanying it can be performed by the same procedure as described above. it can.

As described above, according to the present embodiment, not only the obstacle (7) in the work environment but also the robot arms (5, 6) can generate trajectories that do not intersect each other. Therefore, it is possible to operate the plurality of robot arms on the trajectory without fear of interference. The avoidance control based on the generation of the obstacle and the registration in the obstacle memory according to the present embodiment does not depend on the time axis or the control timing. That is, the sweep (pass) space (region) of the robot arm is registered in the obstacle memory as the maximum range of the position and orientation that the arm can take on the time axis. For this reason, according to the present embodiment, it is possible to reliably generate a trajectory capable of avoiding interference between the robot arms (5, 6) even if a timing shift such as a delay in arm control occurs in the actual environment. Further, since the basic trajectory generation (+ obstacle registration) control shown in this embodiment does not use the exclusive space control in the time axis direction which is performed by the conventional method or the like, it can be executed at a relatively high speed and is excessive. It can be easily executed without the need for various computational resources.

In addition, in this embodiment (the same applies to the following embodiments), a configuration in which one obstacle memory exists in the main memory or the virtual memory is shown for ease of explanation. In that case, the obstacle data includes the identification data of the robot arm (5, 6,...) And in the trajectory generation of a certain arm, it corresponds to the sweep area of the arm other than the obstacle corresponding to the sweep area of the arm itself. It is supposed to avoid obstacles that do. However, various forms of implementation of one obstacle memory on the main memory or virtual memory are conceivable, and those skilled in the art make various design changes regarding implementation of the obstacle memory and a part of control using the obstacle memory. be able to.

For example, an obstacle memory is arranged for each robot arm (5, 6...), and an obstacle corresponding to the sweep area of the arm is added to the obstacle memory other than the relevant arm when the trajectory is generated. Various controls are also possible. Even by implementing such an obstacle memory, it is possible to realize a trajectory generation process for generating a trajectory for operating the robot arm so as to avoid an obstacle space other than the obstacle space registered for the robot arm.

<Example 2>
In the above-described first embodiment, the method of generating the trajectory without interference between the robot arms (5, 6) is described as the simplest example of generating the trajectory from the two motion commands of the robot arms 5 and 6. When the trajectory generation and the obstacle registration are repeated for a larger number of trajectory definition data only by the step configuration as shown in FIG. 5 of the first embodiment, there is a possibility that a new trajectory cannot be generated due to the large number of registered obstacles. There is.

In the basic control of the present embodiment, in order to register the entire region in which the arm body sweeps (passes) by the generated trajectory as an obstacle, the more operation commands to generate the trajectory, the earlier many parts of the work space are registered. It may be filled with obstacles.

Robots that operate in real-world environments such as production lines are typically assigned more work. For example, even when a simple transport operation is performed, it is divided into two operations, that is, an operation of picking up a transported object and an operation of leaving it. That is, it is assumed that the command input by the worker includes a plurality of motions for each robot. Then, in the basic control shown in the first embodiment, in order to generate trajectories in which the passage areas of the plurality of robots do not intersect with each other, the passage area of all the movements performed by the robot is the entire movements of other robots. It is controlled so that it does not cross the passage area of. However, creating such trajectories becomes a more difficult problem to make, as the number of movements assigned to the robot is large and the work space is small.

For example, in FIG. 8C, the trajectory Trb1 (start point Sb1 to end point Gb1) of the robot arm 6 is generated, and the obstacle (SVb1) corresponding to the corresponding sweep (passage) area is registered in the obstacle memory 2201. Is shown. On the other hand, thereafter, it is assumed that an operation command whose start point and end point (Sa2, Ga2) to be generated for the robot arm 5 exists in the operation command list. The trajectory definition of this operation command, particularly the end point (Ga2), already exists in the space of the obstacle (SVb1) as shown in FIG. 8(d). As it is, it is impossible to generate the robot trajectory corresponding to the trajectory definition in which the (start point, end point) in the operation command is (Sa2, Ga2).

Hereinafter, in the present embodiment, a control method capable of continuing trajectory generation and obstacle registration when an event as shown in FIG. 8D occurs when trajectory generation is performed in response to a larger number of operation commands. .. In this case, we also show a control method that allows the robot arms in the real environment to operate without interfering with each other by the generated trajectory.

In the second embodiment, when the robots cannot generate trajectories that do not intersect with each other in response to a given command, the command is divided into two, and a trajectory in which the robots do not intersect with each other in the command after the division is set. To generate.

That is, when a trajectory is generated based on a plurality of trajectory definition data in the motion command list, a trajectory that avoids the obstacle space registered in the obstacle memory may not be able to be generated. In that case, the trajectory definition data in the motion command list includes the first motion command including the trajectory definition data corresponding to the trajectory generated at that time and the second trajectory definition data including the trajectory definition data corresponding to the ungenerated trajectory. It is divided into motion command and. Then, after clearing the data of the obstacle space registered in the obstacle memory, the trajectory generation process and the obstacle registration process are repeatedly executed for the trajectory definition data included in the second operation command. Further, based on all the generated trajectory data, when each robot arm is operated, the operation of the robot arm corresponding to the first operation command and the operation of the robot arm corresponding to the second operation command are synchronized. To generate a synchronous command to be executed dynamically.

Hereinafter, the control of this embodiment will be described with reference to FIGS. 7 to 10 and FIGS. 16(a) to 16(f). Hereinafter, it is assumed that the overall configuration of the trajectory generation system shown in FIG. 1, FIG. 2, FIG. The arrangement of the robot arms 5 and 6 and the obstacle 7 is the same as in FIG.

FIG. 7 shows the flow of the trajectory generation and obstacle registration procedure of this embodiment in the same detailed format as FIG. 5 of the first embodiment. FIGS. 8A to 8D and FIGS. 9A to 9D show the state of trajectory generation in the same detailed format as FIGS. 4 and 6. FIG. 10 shows a state of synchronous control of the motion corresponding to each motion command generated by the trajectory in this embodiment. 16A to 16F show the transition of the data contents of the obstacle memory 2201 of this embodiment in the same format as that of FIG. In the following, the members already described in the first embodiment and the processing steps will not be repeated unless otherwise necessary.

In the present embodiment, the overall flow of the trajectory generation and obstacle registration procedure is the same as that of FIG. 3 of the first embodiment, and the overall flow of the control procedure is the input of operation command and generation of operation command list (S101), priority. It starts from setting (S102). After that, trajectory generation (S103) and obstacle addition (S104) are performed.

Steps S300 (input of operation command and generation of operation command list), S310 (priority setting), S320 (pointer/counter initialization), and S330 (orbit generation of operation command Mi) of FIG. , S210, S220, and S230. S350 (generation of the robot arm passage (sweep) region corresponding to the operation command Mi) and S360 (additional registration of the passage (sweep) region) of FIG. 7 are the same processes as steps S240 and S250 of FIG. Further, S370 (loop end determination) in FIG. 7 is the same process as step S260 in FIG.

7 is substantially different from FIG. 5 in that steps S340 to S380 are performed between S330 (trajectory generation of the operation command Mi) and S350 (passage (sweep) area generation of the robot arm corresponding to the operation command Mi). This is an added point.

In step S340, it is determined whether or not the trajectory corresponding to the operation command Mi was generated in step S330. If the trajectory corresponding to the operation command cannot be generated due to the obstacle sweep space registered in the obstacle memory 2201, the process proceeds to step S380.

In step S380, it is divided into a first motion command including trajectory definition data corresponding to the generated trajectory and a second motion command including trajectory definition data corresponding to the ungenerated trajectory. Then, after clearing the data of the obstacle space registered in the obstacle memory, the process returns to step S300. In this case, in steps S300 and S310, the priority order of processing of each motion command, which is composed of the trajectory definition data corresponding to the ungenerated trajectory in the motion command list (which constitutes the second motion command portion), is determined. Control to do so.

Hereinafter, the processing of FIG. 7 will be described by taking an operation command as shown in FIGS. 8 to 10 as an example.

In step S300 of FIG. 7, as in step S100 (FIG. 3) and step S200 (FIG. 5), an operation command is input and an operation command list is generated. Here, the operation command list generated based on the operator's input includes three operation commands Ma1, Ma2, Ma3 for the robot arm 5 and two operation commands Mb1, Mb2 for the robot arm 6. Be present.

FIG. 8A shows the trajectory definition (start point, end point) corresponding to the operation command. In the figure, the motion commands Ma1, Ma2, Ma3 are the trajectory definitions of the starting points Sa1, Sa2, Sa3, the end points Ga1, Ga2, Ga3, and the motion commands Mb1, Mb2 are the starting points Sb1, Sb2, the end points Gb1, Gb2. Corresponds to the orbit definition of.

That is, in this trajectory definition, the operation command Ma1 is from the start point Sa1 to the end point Ga1 (Sa2) in FIG. 8A, Ma2 is from the start point Sa2 to the end point Ga2 (Sa3), and Ma3 is from the start point Sa3 to the end point Ga3. The reference part is moved. The robot arm 5 starts from the position of Sa1 and goes toward the position of Ga3 via the positions of Ga1 and Ga2.

Further, the operation command Mb1 of the robot arm 6 is an operation command for moving the reference part of the arm from the starting point Sb1 to the end point Gb1 in FIG. 8A, and Mb2 is moving from the starting point Sb2 to the end point Gb2. In this case, the robot arm 6 starts from the position of Sb1 and moves toward the position of Gb2 via the position of Gb1. The operation command list corresponding to this command Op1 has the following configuration.
Op1={Ma1, Ma2, Ma3, Mb1, Mb2}
Ma1=(Sa1, Ga1), Mb1=(Sb1, Gb1)
Ma2 = (Sa2, Ga2), Mb2 = (Sb2, Gb2)
Ma3 = (Sa3, Ga3)
In step S310 of FIG. 7, the order of trajectory generation is determined based on the set priority order. Regarding the control of the priority order of the trajectory generation (robot unit or motion command unit), various methods can be considered as described above, and for example, it is conceivable to allow the operator to specify the priority order.

However, in the present embodiment, it is assumed that the CPU 20 automatically controls the trajectory generation priority order (robot unit or motion command unit). Here, the trajectory generation of the robot arm including a larger number of the trajectory definition data in the operation command list is executed before the trajectory generation of the robot arm including a smaller number of the trajectory definition data in the operation command list. To set the priority. In this case, in the configuration of the operation command list described above, the robot having a large number of operations and having a high priority is the robot arm 5.

Regarding the priority order of operation command units, for example, it is conceivable to rearrange the processing order of each operation command in an arbitrary order according to the input designation of the operator. However, in the present embodiment, in order to facilitate the description, the order of the operation command list (Ma1, Ma2..., Or Mb1, Mb2...) Is used.

However, in the present embodiment, of the plurality of robot arms, the processing order of trajectory generation (+ obstacle registration) of all the arms one by one in order not to generate an arm having a large number of motion commands that have not been generated. Control is also applied. This is to avoid the problem that only one robot concentrates on trajectory generation and other robots cannot generate trajectory depending on the passage area.

Note that an example of the control of the processing order of the trajectory generation (+ obstacle registration) of the present embodiment as described above will be described at the end of the present embodiment using the flowchart of FIG. 18.

According to the control of the processing order of trajectory generation (+ obstacle registration) of the present embodiment as described above, the order of trajectory generation for each operation command is Ma1, Mb1, Ma2, Mb2, Ma3. ..

Subsequent to step S320 (pointer/counter initialization) in FIG. 7, in step 330, trajectory generation is performed in the order determined in step S310. The trajectory generation in step 330 is similar to the processing described in step S230 in FIG.

In step 340 of FIG. 7, it is determined whether or not the trajectory generation is successful in step S330. If the trajectory generation is successful here, the process proceeds to step S350, and if the trajectory generation cannot be generated, the process proceeds to step S380. Here, when the trajectory cannot be generated, for example, when the path to the end point is blocked by the passing area of the other robot arm, or when the starting point and the end point are included in the passing area of the other robot arm. There is a case.

In the example of FIG. 8, first, the operation command Ma1 of the robot arm 5 is processed. In this case, since the trajectory Tra1 from the start point Sa1 to the end point Ga1 and avoiding the obstacle 7 can be generated, the processing step is S350.

In steps S350 and S360, obstacle data is generated from the passage (sweep) area (SVa1) by the trajectory and registered in the obstacle memory 2201. As a result, the state of the obstacle memory 2201 changes from the state in which only the obstacle 7 in FIG. 16A exists to the registered state in FIG. 16B. That is, the passage (sweep) area (SVa1) of the robot arm 5 is newly added as an obstacle by the trajectory Tra1 of the operation command Ma1.

As shown in FIG. 8C, trajectory generation and obstacle addition can be performed for the next operation command Mb1 in the same procedure as above. The motion command Mb1 can also generate a trajectory in steps S330 and S340, and a passage (sweep) region (SVb1) corresponding to the trajectory Trb1 is newly added to the obstacle memory 2201 as shown in FIG. 16C.

The process further proceeds, and in step S330, the trajectory generation of the motion command Ma2 for the robot arm 5 is tried. This operation command Ma2 includes a trajectory definition from the start point Sa2 to the end point Ga2 as shown in FIG. However, as shown in FIG. 8D, the position of the end point Ga2 of the operation command Ma2 is inside the obstacle (SVb1) added in the above procedure and causes interference with the obstacle. Can not be done. In this case, the process proceeds to step S380 in FIG.

In step S380, the CPU 20 performs processing when the trajectory cannot be generated. In this step S380, first, the motion command (group) is not processed for the first motion command (group: first half) for which trajectory generation (+ obstacle registration) has been completed and trajectory generation (+ obstacle registration). 2nd operation command (group: latter half).

That is, all the motion commands for which the trajectory has been generated so far are set as one first motion command (group: first half), and all the motions after the trajectory generation (+ obstacle registration) are unprocessed are the second motions. Divide into commands (group: latter half). In the example of the second embodiment, the operation commands Ma1 and Mb1 are divided into a first (first half: Op1-1) operation command, and the operation commands Ma2, Mb2 and Ma3 are divided into a second (second half: Op1-2) operation command. ..

The division of the first and second motion commands is not limited to once, but if the trajectory generation becomes impossible by the processing of the second motion command in the latter half (remaining), the second motion command is further divided. Is divided into a (processed) first motion command and a (unprocessed) second motion command. By repeating this, all operation command data are processed.

Further, when the division into the first and second operation commands occurs, the operations of the robot arms (5, 6) corresponding to the first and second operation commands are executed synchronously before and after the division. That is, the synchronization control is performed such that the operation corresponding to the second operation command is started after waiting for the completion of all the operations corresponding to the first operation command. In order to perform such synchronization control, when the operation command is divided, the CPU 20 generates a synchronization command (Sp1 in FIG. 10) for synchronizing the operation of the robot in the actual environment as described above. This synchronization command (Sp1 in FIG. 10) is inserted, for example, at the position where division of the generated trajectory data group has occurred.

Then, as shown in FIG. 16D, the CPU 20 clears the obstacle data corresponding to the sweep (passage) region of the robot arm generated by the trajectory generation from the obstacle memory 2201. In this case, the obstacles SVa1 and SVb1 added by the trajectory generation of the operation commands Ma1 and Mb1 are deleted. This makes it possible to generate the trajectory of the motion within the next command.

After that, returning to step S300, the same processing as described above is repeated, and trajectory generation (+ obstacle registration) is executed for the remaining unprocessed second motion command (group: latter half). As a measure for processing from the trajectory definition corresponding to the second motion command (latter half: Op1-2), the CPU 20 performs a process of deleting the processed part of the motion command list in step S380. May be

The first operation command (first half: Op1-1) and the second operation command (second half: Op1-2) obtained by dividing the operation command Op1 as described above are
Op1-1={Ma1, Mb1},
Op1-2={Ma2, Mb2, Ma3}
It becomes the structure like. When the operation command division as described above is performed, the CPU 20 outputs a synchronization command (a synchronization command for synchronously controlling each operation of the divided first (first half) and second (second half) operation commands in an actual environment. Sp1) of FIG. 10 is generated. This synchronization command (Sp1 in FIG. 10) is, for example, inserted at the position where the generated trajectory data group is divided.

In the subsequent processing, in step S300, the processing target becomes the trajectory definition corresponding to the second motion command (latter half: Op1-2) by passing through step S380. That is, the operation command Op1-2 including the operation commands Ma2, Mb2, Ma3 is input.

FIG. 9A shows the current position of the robot arm at the beginning of the process of the second operation command (latter half: Op1-2) and the start points (Sa2, Sb2, Sa3) and end points of the operation commands Ma2, Mb2, Ma3. The position of (Ga2, Gb2, Ga3) is shown.

In the subsequent step 310 of FIG. 7, the order of trajectory generation is determined in the same manner as above. Similarly to the above, for example, the priority of the robot arm is set from the number of operations, and the processing order is determined from the priority. Also in the processing of the second operation command (latter half: Op1-2), the robot arm 5 has a larger number of operations, and thus the priority is set higher. Therefore, the order of the trajectory generation processing is the order of the operation commands Ma2, Mb2, Ma3.

Thereafter, the CPU 20 executes the trajectory generation process and the obstacle registration process in response to the second operation command (latter half: Op1-2) by steps 330 to 360 of FIG. 7 as described above. The first motion command Ma2 is a motion from the start point Sa2 to the end point Ga2. As shown in FIG. 9B, the trajectory is generated by avoiding the point Sb2 which is the current position of the robot arm 6. Tra2 is generated. Further, as shown in (e) of FIG. 16, the passage (sweep) area (SVa2) of the robot arm 6 on the trajectory Tra2 is added to the obstacle memory 2201 as an obstacle.

The subsequent operation commands Mb2, Ma3... Are further processed by steps 330 to 360 of FIG. For the start point Sb2 and the end point Gb2 of the operation command Mb2, the trajectory Trb2 is generated so as to avoid the added obstacle SVa2 (FIG. 9(c)). Further, an obstacle (SVb2) corresponding to the passage (sweep) area of the trajectory is generated and added to the obstacle memory 2201 (FIG. 16(f)). Then, finally, a trajectory Tra3 that avoids the obstacle SVb2 is generated from the start point Sa3 and the end point Ga3 of the operation command Ma3 (FIG. 9D), and the obstacle (SVa3) corresponding to the passage (sweep) area of the trajectory. Is generated.

As described above, the generation of all trajectories corresponding to all motion commands in the motion command list first input by the operator is completed. According to the trajectory generating method of the present embodiment, when the trajectory cannot be generated due to the obstacle corresponding to the passing (sweep) area of the arm, the first motion command including the processed motion command and the unprocessed motion command. The operation command list is divided into a second operation command including the operation command of. At that time, since the obstacle data in the obstacle memory is cleared and the remaining second operation command is processed, the trajectory generation (+ obstacle registration) can be continued.

On the other hand, according to the trajectory generation as described above, in the operation in the real environment, there is a possibility that the robot arms may interfere with each other between the divided operation commands Op1-1 and Op1-2, so that synchronous execution control is performed. There is a need. For example, control is performed to execute the operation within the second operation command Op1-2 after all the operations within the first operation command Op1-1 are completed. For this reason, when the operation command is divided as described above, the CPU 20 inserts the synchronization command (Sp1 in FIG. 10) into the orbital data at the position requiring the synchronization control.

FIG. 10 shows a case where the robot operations corresponding to the (first) operation command Op1-1 and the (second) Op1-2 divided as described above are synchronously executed by the robot arms 5 and 6. The timing is shown. This example corresponds to the (first) operation command Op1-1 and the (second) operation command Op1-2 described with reference to FIGS. When the (first) operation command Op1-1 and the (second) operation command Op1-2 are divided in this way, the CPU 20 inserts the synchronization command (Sp1) into the trajectory data. Thus, synchronous control is performed so that the operation corresponding to the (second) operation command Op1-2 is started after all the operations of the (first) operation command Op1-1 are completed. You can

In FIG. 10, first, the two robot arms 5 and 6 simultaneously start their respective operations. In this case, one of the robot arms ends its operation first, but if the synchronization command (Sp1) is inserted, the operation of the next command is not executed, and the operation of the other robot arm Wait for completion. In the example of FIG. 10, the robot arm 6 completes the operation (Mb1) first, but the synchronous control is performed so that the robot arm 6 waits only for the waiting time 80 and waits for the operation command Ma1 of the robot arm 5 to complete. ing. Then, after all the operations in the operation command Op1-1 are completed, the operation moves to the next operation command Op1-2, and the respective operations (Ma2, Mb2, Ma3...) Are started simultaneously.

Note that if the operation command is divided (and the obstacle memory 2201 is cleared) between the operation command Op1-2 and the subsequent operation command (not shown), as shown in FIG. Sp2) is inserted. Here, the robot arm 6 completes all operations first, but here again, the synchronous control of waiting for the robot arm 5 for the waiting time 90 is performed.

As described above, in the present embodiment, in the command after the division, the trajectory in which the plurality of robot arms do not interfere with each other is guaranteed, and the interference between the commands causes the robot arms to operate synchronously based on the synchronization command. Thus, according to the method of the present embodiment, even when a large number of movements are assigned to the robot arm, the synchronization command is generated and the simple synchronization control in the actual environment is performed, thereby causing the interference between the robots. No trajectories can be generated automatically.

Here, the processing order of trajectory generation (+ obstacle registration) is set by using the priority of the robot arm unit and the motion command unit described in step S310 of FIG. 7 (the same applies to step S210 of FIG. 3) in FIG. An example of the controlling algorithm will be shown.

Here, a pointer (counter) R indicating the priority of each robot arm is used. This R is incremented by 1 from the value 0 corresponding to the maximum priority to R _M corresponding to the maximum (total) robot arm number. On the other hand, in the robot arm order list secured in the main memory or virtual memory pointed by the pointer (counter) R, the identification data of each robot arm is specified based on the user (worker) designation (or automatically determined by the CPU 20). Are stored in descending order of priority. By referring to this robot arm order list from the beginning (0) based on the value of the pointer (counter) R, the CPU 20 generates a trajectory in the order of the arms defined in the robot arm order list (+ obstacle registration). Can be executed. The pointer (counter) R is cyclically used in the example of FIG. 18, and when the value reaches R _M corresponding to the maximum (total) number of robot arms, the value is reset to 0.

Further, in the above, the priority control in units of operation commands using the pointer (counter) i has not been described in detail, but the same configuration as above can be used for the priority control in units of operation commands. .. For example, priority is given to the identification data of each operation command based on the user (worker) designation (or automatically determined by the CPU 20) in the operation command order list secured in the main memory or virtual memory indicated by the pointer (counter) i. Store in order from the highest ranking. By referring to this operation command order list based on the value of the pointer (counter) i (the highest priority is 0), the operation commands can be processed in the definition order of the operation command order list.

FIG. 18 is a flowchart showing the details of steps S320 to S370 of FIG. 7. Step S320 is the same pointer (counter) i initialization (i=0) processing as that of FIG. Further, the subsequent step S520 is initialization (R=0) processing of the pointer (counter) R described above.

In step S530, the operation command to be processed this time is determined by a pointer (counter) operation such as Mi=Mi(R). That is, this pointer (counter) operation is a process for specifying the highest priority (unprocessed) operation command at the present time regarding the robot arm pointed to by the pointer (counter) R.

In step S540, trajectory generation and obstacle registration processing corresponding to the processing of steps S330 to S360 of FIG. 7 is performed. Although not shown in detail here, the operation command division processing of steps S340 to S380 when the trajectory cannot be generated can be similarly executed.

In step S550, the pointer (counter) R and the pointer (counter) i are incremented by 1 (R=R+1, i=i+1). As a result, the pointers (counters) R and i are incremented so that the robot designation and the motion command point to the next robot arm and the next motion command, respectively.

In step S560, it is determined whether or not the pointer (counter) R has made one round, that is, whether or not it has reached R _M corresponding to the maximum (total) number of robot arms. If step S560 is positive, the pointer (counter) R is reset to 0 to point to the first highest priority arm.

Step S580 is the same process as step S370 of FIG. 7, and here it is determined whether all the operation commands in the operation command list have been processed by the determination of the value of the pointer (counter) i. Here, while all the operation commands are not processed, it returns to step S530 and repeats the above operation.

By incrementing the pointer (counter) R by the priority processing as shown in FIG. 18, all robot arms are designated one by one in the order of the set priority, and the operation command is prioritized by the pointer (counter) i. It can be taken out and processed in order of degree. Therefore, with respect to the priority control for each robot arm, it is possible to uniformly process the operation commands of all the robot arms based on the priority order in the set priority order. Therefore, for example, there is a bias in the specification of the robot priority of the user (worker), and the operation of a certain robot arm is processed earlier, and the trajectory generation does not proceed in the processing of the operation of the subsequent robot arm. It can be avoided.

<Example 3>
As a situation in which the trajectory generation is impossible in the second embodiment, for example, as shown in FIG. 8D, the end point Ga2 of the trajectory generation (the same applies to the start point) is generated by the trajectory generation of another robot arm. An example is shown in which an obstacle (SVb1) is interfered with from the beginning. In the third embodiment, a processing method that can avoid such a situation will be described. Also in this embodiment, the basic configuration of the trajectory generation system shown in FIGS. 1 to 4 and 14 is similar to that of the above-described first and second embodiments, and the members and controls already described are as far as possible. The duplicate description will be omitted.

In the third embodiment, the above problem is solved by registering the space occupied by the skeleton of each robot arm as an obstacle in the posture when the robot arm is at the starting point and the ending point, which are the trajectory definitions in the motion command. To avoid. As a result, it is possible to avoid a situation in which the start point or the end point of the operation command is included in the passage area of another robot arm from the beginning.

Hereinafter, the processing method of this embodiment will be described with reference to FIGS. 11 to 13 and 17 for a method of generating a trajectory in which the passage areas of a plurality of robots do not intersect each other in the third embodiment. 11A to 11F show the posture of each robot arm (5, 6) and the corresponding trajectory generation (+ obstacle registration) in the same format as FIG. 8 of the second embodiment. FIG. 12 shows a state of synchronous robot control in a real environment corresponding to FIG. 10 of the second embodiment, and FIG. 13 shows the trajectory generation (+ obstacle registration) in the present embodiment in the same format as FIG. The control procedure is shown. Further, FIGS. 17A to 17F show the transition of the data contents of the obstacle memory 2201 of the present embodiment in the same format as FIGS. 15 and 16.

Hereinafter, the configuration of the third embodiment and the operation command in the operation command list to be processed are the same as those of the second embodiment. Therefore, in the following description, the points different from the second embodiment will be particularly emphasized.

In this embodiment, the operation command list generated in response to the operator's input is the same as that in the second embodiment,
Op1={Ma1, Ma2, Ma3, Mb1, Mb2}
Ma1 = (Sa1, Ga1), Mb1 = (Sb1, Gb1)
Ma2 = (Sa2, Ga2), Mb2 = (Sb2, Gb2)
Ma3 = (Sa3, Ga3)
It is composed of operation commands such as. The positions of the start point and the end point are as shown in FIG.

FIG. 13 shows the flow of the trajectory generation (+ obstacle registration) processing in this embodiment. Here, the same processing steps as those in FIG. 7 of the second embodiment use the same step numbers as in FIG. 13 differs from FIG. 7 in that step S410 is inserted between steps S300 and S310. The processing of the other steps is similar to that described with reference to FIG. 7.

In step S410 of FIG. 13, before starting the generation of all trajectories, the robot occupies the space occupied by the skeleton of each arm in the posture when the robot arm is at the start point and the end point in the operation command as an obstacle. Register in the memory 2201. FIG. 17A shows the state after step S410 is executed. That is, in FIG. 17A, the skeleton of each arm occupies the posture at the start point (Sa1, Sa2..., Sb1, Sb2...) And the end point (Ga1, Ga2..., Gb1, Gb2...) Of each operation command. The area is registered in the obstacle memory 2201 as an obstacle.

The subsequent process flow is the same as that described with reference to FIG. 7. For example, the method of determining the priority order of the processing in step S310 is performed in the same manner as in the second embodiment, and here, it is assumed that the processing order of the operation command Op1 is Ma1, Ma2, Ma3, Mb1, Mb2.

Next, following the initialization in step S320, the loop of steps S330 to S370 (and S380) performs trajectory generation and obstacle addition processing in accordance with the set order. At this time, according to the initial registration state of the obstacle as shown in FIG. 17A, in the trajectory generation (step S330) of the present embodiment, the positions of the start point and the end point of the arm other than the arm to be processed are avoided. A trajectory will be generated.

The state of the trajectory generation and the additional registration of the obstacle is as shown in FIGS. 11A to 11F and FIGS. 17B to 17F, for example. Here, first, when the trajectory of the operation command Ma1 is generated, the trajectory Tra1 is generated so as to avoid the obstacle 7 arranged in advance, and the sweep (passage) region thereof is added to the obstacle memory 2201 as the obstacle (SVa1). (FIG. 11(b), FIG. 17(b)).

Then, when the trajectory of the operation command Ma2 is generated, the trajectory Tra2 is generated so as to avoid the position of the end point Gb1 (start point Sb2) of the robot arm 6 that has already been registered as an obstacle ((c) of FIG. 11). .. Further, the sweep (passage) area of the robot arm 6 by the trajectory Tra2 is added to the obstacle memory 2201 as an obstacle (SVa2) (FIG. 17(c)). As a result, unlike the case of the control of the second embodiment, it becomes possible to prevent the trajectory of the subsequent operation command Mb1 from becoming unusable.

Similarly, the trajectory Tra3 of the operation command Ma3 is generated so as to avoid the position of the end point Gb1 (start point Sb2) of the robot arm 6, and its passage (sweep) area is added to the obstacle memory 2201 as an obstacle (SVa3). (FIG. 11(d), FIG. 17(d)).

Further, when the trajectory of the robot arm 6 is generated subsequently, the trajectory is generated so as to avoid the passage area added in the previous procedure, as in the second embodiment. This is because the start and end points of other robot arms are included in the passage area. Therefore, in the trajectory generation of the robot arm 6, the trajectory Trb1 of the operation command Mb1 is first generated, and the passage (sweep) area thereof is added to the obstacle memory 2201 as the obstacle (SVb1) (FIG. 11(e), FIG. 17(e)). Then, for the operation command Mb2, the trajectory Trb2 ((f) in FIG. 11) is generated, and the corresponding passage area is added to the obstacle (SVb2) obstacle memory 2201 (FIG. 17(f)).

By the above, the trajectory generation of all the motions given as the motion command Op1 is completed. FIG. 12 is a time chart when the two robot arms 5 and 6 that have generated trajectories as described above are operated. In the case of the above operation command Op1, in the present embodiment, the spaces corresponding to the postures of the arm body at the start point and the end point of the operation command are registered as obstacles in advance before the start of the trajectory, so steps S340 to S380 in FIG. Has not branched. Therefore, it is not necessary to perform the synchronous control as shown in FIG. 10, and as shown in FIG. 10, the robot arms 5 and 6 start their respective operations at the same time, and the robot arms 5 and 6 give the same regardless of the operations of other robot arms. Interference between the arms does not occur even if the trajectory of the specified movement is executed.

That is, according to the third embodiment, the spaces corresponding to the postures of the arm skeletons at the start point and the end point of the motion command (in a sense, as an established obstacle) are registered in advance (in advance) as obstacles, and Correct the trajectory to avoid it. For this reason, the probability of activating each process of dividing the operation command described in the second embodiment, clearing obstacle data, and generating a synchronization command for synchronously controlling the arm operation in the actual environment is lowered, and the arms are not connected to each other. It is possible to smoothly generate a trajectory without interference of. Then, even when the robot arm is operated by the trajectory data generated in the actual environment, the probability that the synchronous control as shown in the second embodiment is required is reduced, and the robot arm can be operated at high speed.

The specific configurations in the above-described embodiments are merely examples, and do not limit the scope of the claims. The technology described in the claims includes various modifications and changes of the specific examples illustrated above, and it is understood that those skilled in the art can make various design changes within the scope of the claims. Not too long.

The present invention supplies a program that implements one or more functions of the above-described embodiments to a system or apparatus via a network or a storage medium, and one or more processors in a computer of the system or apparatus read and execute the program. It can also be realized by the processing. It can also be realized by a circuit (for example, ASIC) that realizes one or more functions.

DESCRIPTION OF SYMBOLS 1... Arithmetic processing part, 11... Orbit generation part, 2... Input part, 3... Storage part, 5... Robot arm (A), 6... Robot arm (B), 11... Keyboard, 12... Mouse, 13... Display, 51, 52, 53, 61, 62, 63... Joint axis, 54, 64... End effector, 55, 56, 57, 65, 66, 67... Link, 7... Obstacle, 80, 90... Standby time.

Claims (15)

A robot trajectory generation method in a controller for generating a trajectory of a robot arm, comprising:
A storage process in which the control device stores in the memory space data corresponding to a space through which the body of the first robot arm passes based on the trajectory definition data and which the second robot arm should avoid passing; ,
Wherein the controller, while avoiding space corresponding to the space data, have a, a generating step of generating the trajectory second robot arm is operated,
A robot trajectory generation method characterized in that, after generating the spatial data, if a new trajectory that avoids a space corresponding to the spatial data cannot be generated, the spatial data is cleared . The robot trajectory generation method according to claim 1 , further comprising a transmission step of transmitting the trajectory generated in the generation step to the second robot arm. The robot trajectory generation method according to claim 1, wherein the space data includes information about an obstacle arranged in an operable area of the robot arm. Robot path generation method according to any one of claims 1 to 3, further comprising a setting step for setting an operation sequence of the plurality of robotic arms. Robot path generation method according to any one of claims 1 to 4, further comprising a display step for displaying the images corresponding to a plurality of robot arms which are arranged in a virtual space on the display device. The robot according to any one of claims 1 to 5 , further comprising an operation stroke that enables a start point and an end point of the trajectory to be set by operating a robot arm displayed in a virtual space. Orbit generation method. A robot trajectory generation program for causing the control device to execute each stroke according to any one of claims 1 to 6 . A computer-readable recording medium that stores the robot trajectory generation program according to claim 7 . A robot trajectory generating device for generating a trajectory of a robot arm,
A memory that stores space data corresponding to a space through which the body of the first robot arm passes based on the trajectory definition data and the second robot arm should avoid passing;
Generating means for generating a trajectory along which the second robot arm operates while avoiding a space corresponding to the space data ,
A robot trajectory generation device characterized by clearing the spatial data when a new trajectory avoiding a space corresponding to the spatial data cannot be generated after the spatial data is generated . The robot trajectory generation device according to claim 9 , further comprising a transmission unit that transmits the generated trajectory to the second robot arm. The robot trajectory generation device according to claim 9 or 10 , wherein the space data includes information about an obstacle arranged in an operable area of the robot arm. 12. The robot trajectory generation device according to claim 9 , further comprising setting means for setting the operation order of the plurality of robot arms. 13. The robot trajectory generation device according to claim 9 , further comprising display means for displaying images corresponding to a plurality of robot arms arranged in a virtual space. The robot according to any one of claims 9 to 13 , further comprising operating means for setting a start point and an end point of the trajectory by operating a robot arm displayed in a virtual space. Orbit generator. The manufacturing method according to claim 1, wherein the control device operates the robot arm based on a trajectory generated by the robot trajectory generation method according to any one of claims 1 to 6 , and manufactures an article by the robot arm. Method.

Images