Synchronization of multiple robots
11305429 · 2022-04-19
Assignee
- Atensor Engineering And Technology Systems GmbH (Steyr-Gleink, AT)
- Convergent Information Technologies GmbH (Haid, AT)
Inventors
Cpc classification
B25J9/1682
PERFORMING OPERATIONS; TRANSPORTING
B25J9/1676
PERFORMING OPERATIONS; TRANSPORTING
B25J9/0084
PERFORMING OPERATIONS; TRANSPORTING
G05B2219/39135
PHYSICS
G05B2219/39097
PHYSICS
International classification
Abstract
In the following, a method for synchronizing the motion sequences of at least two robots will be described. In accordance with one embodiment, the method comprises the following: During operation of a robot cell having at least two robots, a path parameter is regularly calculated for each of the at least two robots based on a current position of the respective robot and on a previously specified robot path of the respective robot. The path parameter represents the current position of the robot. Subsequently, a run-ahead limit is calculated for each robot based on the path parameters determined for the respective other robots. Based on the respective calculated run-ahead limit, the path speed of every robot can be adjusted.
Claims
1. A method for synchronizing motion sequences of at least two robots whose areas of operation overlap temporally and spatially; the method comprising: during the motion of the at least two robots: regularly determining a path parameter for every robot of the at least two robots based on a current position of a respective robot and a previously specified robot path of the respective robot, wherein the path parameter represents a current position of the respective robot; for every robot: calculating a run-ahead limit based on a path parameter determined for each respective other robot; for every robot: adjusting the path speed of the respective robot based on the corresponding calculated run-ahead limit; and wherein the previously specified robot path of the respective robot is not altered.
2. The method in accordance with claim 1, further comprising; providing the specified robot paths in parametric representation for each of the at least two robots, wherein, for each robot, the path parameter designates a robot position on the specified robot path.
3. The method in accordance with claim 1, further comprising; for every ordered pair of robots of the at least two robots: calculating, based on a simulation of the previously specified robot paths and for various path parameter values, a maximum run-ahead time, wherein the maximum run-ahead time is a time by which a first robot of the ordered pair of robots can run-ahead of a second robot of the ordered pair of robots without causing a collision.
4. The method in accordance with claim 3, further comprising; for every ordered pair of robots of the at least two robots and a given path parameter: calculating an anticipatory maximum run-ahead time based on the maximum run-ahead time for the given path parameter and following path parameters.
5. The method in accordance with claim 4, wherein the run-ahead limit for every robot is determined based on the anticipatory maximum run-ahead times for the determined path parameter of each respective other robot.
6. The method in accordance with claim 1, wherein the determination of the path parameter of a robot is based on an interpolation between two positions that define a segment of the previously specified robot path of the respective robot.
7. A system including at least two robots, each of which is controlled by a robot controller; each robot controller being configured to, while the robots are in operation: regularly determine a path parameter for each robot representing a current position of the respective robot based on a current position of the respective robot and a previously specified robot path of the respective robot, wherein the previously specified robot path of the respective robot is not altered; calculate a run-ahead limit for each robot based on the path parameters determined for each respective other robot; and adjust a path speed of the robot based on the run-ahead limit calculated for the respective robot.
8. The system in accordance with claim 7, further comprising: a robot simulator configured to determine for every ordered pair of robots of the at least two robots and for various path parameter values, based on a simulation of the previously specified robot paths, a maximum run-ahead time, wherein the maximum run-ahead time is the time by which a first robot of the robot pair can run ahead of a second robot of the robot pair without causing a collision.
9. The system in accordance with claim 8, wherein the robot simulator is further configured to calculate, for every ordered pair of robots of the at least two robots and for a given path parameter, an anticipatory maximum run-ahead time based on the maximum run-ahead time for the specific path parameter and following path parameters.
10. The system in accordance to claim 7, wherein the robot controllers are configured to; determine, based on a interpolation between two positions and two corresponding path parameter values which define a segment of the previously specified robot path of the respective robot, the path parameter representing the current position of the respective robot.
11. The method of claim 1, wherein the path parameter is a time parameter identifying a specific position included in the previously specified robot path of the respective robot.
12. The method of claim 1, wherein the path parameter is a single time parameter.
13. The method of claim 1, wherein the run-ahead limit is determined based on the maximum run-ahead times, which are calculated for each robot in relation to another robot(s).
14. The method of claim 11, wherein the maximum run-ahead time of a robot represents the maximum time the robot may run ahead as compared the previously specified robot path in order to avoid a collision with another robot.
Description
BRIEF DESCRIPTION OF THE FIGURES
(1) In the following, the application will be described in greater detail by means of the examples shown in the figures. The representations are not necessarily true to scale and the application is not limited to the aspects shown. Instead, emphasis is placed on illustrating the underlying principles of the application. The figures show:
(2)
(3)
(4)
(5)
DETAILED DESCRIPTION
(6)
(7) As mentioned further above, a work operation (process) that is to be carried out by robots is preceded by the programming of the motion sequences (defining, online or offline, the robot path and the path speed) of the individual robots and of each operational step. These programmed paths can be subsequently validated with the aid of a robot simulator (virtual robot cell). Thereby, it is particularly tested whether and under what circumstances collisions or other problems might arise. After the motion sequences are successfully tested (validation), they can be automatically converted into robot programs that are then implemented by the controllers of the individual robots.
(8) A robot path can be represented mathematically as mapping (function B.sub.i) a time interval [0, T], during which a robot R.sub.i traverses the path, to a configuration position B.sub.i(t) in a configuration space .sup.n.sup.
(9)
wherein k designates the number of robots in considered the robot cell and n.sub.i is the number of degrees of freedom of the i-th robot R.sub.i. The vector representing the configuration position B.sub.i(t) usually contains the joint angles a.sub.1, . . . , a.sub.n.sub..sup.n.sup.
(10) In order to prevent a collision, the volumes occupied by the robots R.sub.i (i=1, . . . , k) in three-dimensional space .sup.3 is considered during a collision test. The volume occupied by the robot R.sub.i in a configuration position (axle configuration) (or the enveloping surface of the robot), can be regarded as a mapping (function P.sub.i) of the configuration position B.sub.i(t) in the configuration space
.sup.n.sup.
.sup.3, i.e.
(11)
wherein S.sub.i is a subset of the three dimensional space .sup.3 (S.sub.i⊂
.sup.3) and designates the volume occupied by the robot R.sub.i in a given axle configuration (a.sub.1, . . . , a.sub.n.sub.
(
.sup.3) designates the power set of
.sup.3). Two configuration positions B.sub.i(t) and B.sub.j(t) are collision free when the intersection of the corresponding volumes P.sub.i(B.sub.i(t)) and P.sub.j(B.sub.j(t)) is empty, i.e.
P.sub.i(B.sub.i(t))∩P.sub.j(B.sub.j(t))={ }, for i≠j. (3)
A so-called 3D collision test can then be carried out by evaluating the condition in accordance with Equation 3 for two configuration positions B.sub.i(t) and B.sub.j(t) of two robots R.sub.i and R.sub.j. If the intersection is not empty, the robots will collide.
(12) As mentioned above, a collision test conducted “offline” with the aid of a robot simulation alone is insufficient, because “online”, i.e. while the robots are carrying out their motion sequences, the time behavior is dependent on influences that could not be foreseen in the simulation. It is therefore desirable, or even necessary, to also conduct a collision test during operation of the robots, i.e. to calculate collisions in advance in order that counter measures (e.g. braking, emergency stop, etc.) may be taken in advance. During the simulation/validation of the planned robot path a 3D collision test is conducted “offline”, which is relatively costly (with regard to computing capacity). Conducting continuous 3D collision testing throughout the run-time of the robot would require large quantities of 3D data for representing the involved objects as well as massive computing capacities. There is therefore a need for alternative approaches.
(13) With the aid of the method described here, it is possible to carry out a collision test “online” in an easy manner. When doing so, for each pair of robots R.sub.i, R.sub.j at every point in time t, only a single parameter is required, which is designated as maximum run-ahead time and which can be determined with the aid of a simulation of the robot paths in a virtual robot cell. Assuming that the robot R.sub.i, at any given point in time t (wherein t∈[0, T]), is at its previously planned target position B.sub.i(t.sub.0) (in the configuration space .sup.n.sup.
ν.sub.ij:[0,T].fwdarw.[0,T],tmax{Δt|P.sub.i(B.sub.i(t))∩P.sub.j(B.sub.j(t+Δt))={ }}. (4)
The maximum run-ahead time ν.sub.ij(t) can be determined “offline” (by means of simulation in a virtual robot cell) and saved for every pair of robots R.sub.i, R.sub.j and every (simulated) point in time. All that is now needed by the robot controllers during the run time of the robots are the maximum run-ahead times ν.sub.ij(t) that were determined in advance by means of the simulator in a sufficiently precise temporal resolution in order that the maximum possible movement between the calculated points in time be incapable of causing an infringement of the specified safety distances. A costly 3D collision test can thus be avoided. For points in time within an interval between two consecutive calculated time points, the minimum of the two calculated maximum run-ahead times can be assumed.
(14)
(15) The maximum run-ahead times ν.sub.ij(t) determined by means of the simulation are variable and depend on the path parameter t (simulation time). It can therefore happen that the maximum run-ahead time for a specific robot R.sub.j, at a point in time to (for a path parameter to) is very large (e.g. infinite), while, at a later point in time t.sub.i (for a path parameter t.sub.i), it can be relatively small (e.g. nearly zero). Thus, although a relatively long run-ahead Δt may be, at the point in time t.sub.0, unproblematic, the same run-ahead time Δt may be too large at the point in time t.sub.i and may result in a collision. Hence, the robot controller must “anticipatorily” take into account the maximum run-ahead times ν.sub.ij(t). In the present example, therefore, the run-ahead time Δt at the point in time to may not be of just any desired duration (the condition Δt<ν.sub.ij(t.sub.0) is necessary, but not sufficient), but instead must be kept short enough to ensure that staying within the maximum run-ahead time ν.sub.ij(t.sub.1) at a later point in time t.sub.1 is still possible. This “anticipatory” consideration of the maximum run-ahead times ν.sub.ij(t) can, for example, be achieved by transforming the maximum run-ahead times ν.sub.ij(t) into “anticipatory maximum run-ahead times” w.sub.ij(t). This transformation can be carried out in various ways (e.g. while taking into account the maximum possible braking accelerations). One simple and safe option (with regard to a worst case scenario) consists in using, at every point in time t (in the simulation time), the shortest maximum run-ahead time from among the maximum run-ahead times ν.sub.ij(t) in each time interval [t, T] (i.e. from the current point in time to the end of the planned motion sequence). In this case the anticipatory maximum run-ahead time w.sub.ij(t) can be calculated using the following equation:
w.sub.ij:[0,T].fwdarw.[0,T],tmin{ν.sub.ij(t+u)+u|u∈[0,T−t]}. (5)
This means that, if, for a pair of robots R.sub.i, R.sub.j at time point t=0, the maximum run-ahead time ν.sub.ij(0) of the robot R.sub.j is infinitely long and the maximum run-ahead time ν.sub.ij(1) for a point in time t=1 s is only 0.3 s, then the anticipatory maximum run-ahead time w.sub.ji(0) at the point in time t.sub.0 is not, in fact, infinite, but rather maximum 1.3 s. Thus, the anticipatory maximum run-ahead time w.sub.ij(t.sub.0) at a point in time t.sub.0 also takes into account the maximum run-ahead times ν.sub.ij(t.sub.0) for later points in time t>t.sub.0 (and t<T).
(16) In order to synchronize numerous robots of a robot cell while taking into account the calculated anticipatory maximum run-ahead times w.sub.ji(t) and thus prevent collisions, all anticipatory run-ahead times w.sub.ji(t) (for all i≠j) for the robot R.sub.j must be available to the robot controller. During run time, the robot controllers of the individual robots R.sub.i (i=1, . . . , k) indirectly exchange information about their “progress” while moving along their robot paths, i.e. about their current positions (in the configuration space) by exchanging the path parameters that designate their respective positions on the previously determined robot path. For each robot R.sub.j, the corresponding robot controller can calculate its own current run-ahead time limit t.sub.ν,j(t) based on the anticipatory maximum run-ahead times w.sub.ji(t) calculated in advance by means of simulation and on the current simulation times t.sub.i(t) (path parameters) of the other robots R.sub.i (i≠j). The current run-ahead time limit t.sub.ν,j(t) for the robot R.sub.j is the minimum of the anticipatory maximum run-ahead times w.sub.ji(t) with regard to the other robots R.sub.i (for all i≠j), meaning:
t.sub.ν,j:[0,T].fwdarw.[0,T],tmin{w.sub.ij(ti(t))|für alle i≠j}. (6)
(17) For every robot R.sub.j (j=1, . . . , k), the path speed can be adapted in dependence of the current run-ahead time limit t.sub.ν,j(t). For this purpose, the robot controller of the respective robot R.sub.j can determine—at every point in time t—a current braking time t.sub.B,j. As a rule, this braking time t.sub.B,j is dependent on the current path speeds and the maximum braking delays of the robot axes of the robot R.sub.j. As long as the braking time t.sub.B,j for the respective robot R.sub.j is shorter than the current run-ahead time limit t.sub.ν,j(t), i.e. as long as the inequality
t.sub.B,j(t)<t.sub.ν,j(t) (7)
is fulfilled, the path speed of the robot R.sub.j may be increased (up to a definable maximum value). In this case the robot tries to run ahead as far as possible, causing the other robots to “catch up”. As soon as the current braking time t.sub.B,j becomes longer than the run-ahead time limit t.sub.ν,j(t), the path speed of the robot must be reduced until Inequality 7 is once again fulfilled.
(18) In the following, the method described above will now be summarized with reference to the flow chart. During operation of a robot cell having at least two robots, a path parameter t.sub.j is regularly (periodically or from time to time) determined for each robot R.sub.j based on its current position B.sub.j(
(19) In order to calculate the run-ahead limits t.sub.ν,j(t) of the individual robots R.sub.j, first of all the maximum run-ahead times ν.sub.ji(t) and the anticipatory maximum run-ahead times w.sub.ji(t) are determined, as described above. Accordingly, for every ordered pair of robots R.sub.j, R.sub.i a maximum run-ahead time ν.sub.ji(t) is calculated—by means of simulation of the (parameterized) robot paths specified in advance and for a series of path parameter values. This is the time by which the first robot R.sub.j of a pair of robots may run ahead of the second robot R.sub.i of the robot pair without causing a collision (cf. Equation 4). The mentioned series of path parameter values is created by means of discretization of the interval [0, T] in which the respective robot path B.sub.j(t) is defined. The maximum run-ahead time ν.sub.ji(t) for a given path parameter t (simulation time) alone is not enough as the maximum run-ahead time ν.sub.ji(t) is not a constant value and may change. For this reason, a so-called anticipatory maximum run-ahead time w.sub.ij(t.sub.0) is calculated for every ordered pair of robots R.sub.j, R.sub.i and for a given path parameter t.sub.0 (the above mentioned series of path parameters) based on the maximum run-ahead time ν.sub.ij(t.sub.0) for the given path parameter t.sub.0 and the following path parameter (t>t.sub.0) in the series of path parameters (see Equation 5). The information on the maximum run-ahead times allows every robot to strive on its own to reach the highest speed it can without colliding with the other robots. A regulator for the speed is not needed. Thus, the synchronization of numerous robots is greatly simplified.
(20) In the following an example will be used to describe how the corresponding path parameter (here: simulation time) can be determined in the robot program based on a detected robot position q.sub.j of a robot R.sub.i. In order to keep the data volume and the computing effort for the robot controller small, to control the robot R.sub.i, the corresponding robot path B.sub.i(t) is divided up into numerous segments S.sub.ij (segment S.sub.ij is the j-th of s.sub.i segments of the path B.sub.i(t) of the robot R.sub.i, j=, . . . , s.sub.i):
S.sub.ij:[T.sub.ij,T.sub.i(j+1)].fwdarw..sup.ni,t
B.sub.i(t), wherein T.sub.i0=0 and T.sub.i(si+1)=T. (9)
The time T.sub.ij is the starting time of the j-th segment of the path B.sub.i(t) of the robot R.sub.i. The time T.sub.i(j+1) is the ending time of the j-th segment S.sub.ij and is likewise the starting time of the (j+1)-th segment S.sub.i(j+1). The desired motion sequences are communicated by the robot controller to the robot R.sub.i by means of motion sets. The j-th motion set for the robot R.sub.i is given by
MOV.sub.ij={B.sub.i(T.sub.ij),B.sub.i(T.sub.i(j+1))} (10)
(21) While carrying out the motion sequence defined by a motion set MOV.sub.ij, the current configuration position q.sub.i (e.g. vector of the joint angle and also the axis configuration) of the robot R.sub.i can be measured in short time intervals. The simulation time t.sub.i can now be determined by means of a simple interpolation between the starting point and the end point of the motion set MOV.sub.ij and the measured configuration position q.sub.i. For the simulation time t.sub.i, it holds true that B.sub.i(t.sub.i)≈q.sub.i.
(22) The procedure described above is summarized in the flow chart in accordance with