Data processing: generic control systems or specific application – Specific application – apparatus or process – Robot control
Reexamination Certificate
2002-05-30
2004-01-13
Cuchlinski, Jr., William A. (Department: 3661)
Data processing: generic control systems or specific application
Specific application, apparatus or process
Robot control
C700S247000, C700S251000, C700S254000, C700S258000, C700S259000, C700S260000, C700S262000, C318S568110, C318S568120, C318S568240, C318S580000, C318S587000, C318S646000, C318S648000, C701S050000, C701S211000, C701S212000, C701S213000, C701S214000, C701S215000, C701S301000, C901S001000, C901S009000, C901S015000, C901S014000
Reexamination Certificate
active
06678582
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to a method of avoiding collisions between a robot and at least one other object, and to a control device for avoiding collisions between a robot and one or several other objects suited for implementation of the inventive collision avoidance method.
BACKGROUND OF THE INVENTION
According to a general definition two objects A and B are in collision if they share the same space at the same time. That is, there is at least one point in A and one point in B that have the same coordinates with respect to a common frame of reference.
Robots and other objects between which collisions are to be avoided are generally referred to as cooperative mechanisms, since they cooperate in a certain industrial process. The cooperation can be either active (in the case of one robot cooperation with another robot as an example of a cooperative mechanism) or passive. With modern industrial robots moving at considerable velocities, collisions can result in serious damage to both the robots and the work pieces handled by them and may lead to costly production downtimes. Therefore, such collisions must by all means be avoided if an efficient use of industrial robots is to be realized.
Several types of collisions can occur in a working area, i.e. in a workcell shared by a robot and other (moveable) objects. There are several factors to take into consideration when classifying collisions, particularly: (i) The type of objects in question, i.e. robots/machines, stationary objects, etc. (ii) The reason for collision, i.e. path changes, sensory data changes, programming errors, etc. (iii) The production phase, i e. does the collision occur at teach time (manual mode), validation time (automatic mode) or during normal production (automatic mode with application—preferably high—speeds).
A passive stationary object is an object that is fixed in the workcell and has a fixed shape. Examples of passive stationary objects are fixed tables, poles, etc. Obviously, these objects are not controlled by any controller. However, a static geometry model can be obtained and stored so that collision could be checked for. A distinction has to be made between the robot body (links) and the load (tools or workpieces). There could be a permanent potential collision between the robot body and an object. The potential for collision between a tool and the object exists as long as the tool is not linked to any frame on the object. Once the link has been established, (the tool is moving relative to a frame on the object) there is no potential collision between the tool and the object, except during manual operation, e.g. teaching phases or in case of programming errors.
An active stationary object is an object that is fixed in the workcell but that has a variable shape. Examples of active stationary objects are fixtures and palettes (varying heights). Usually robot controllers do not control such objects, thus they do not have any knowledge about their states (open/closed, height etc.). This makes it difficult to check for collision with such objects. However, the collision probability could be eliminated by considering the object as a passive stationary object whose volume is the largest volume possibly occupied by the active stationary object. The distinction between robot body and load mentioned above applies here, too.
A moving object is an object whose position (location and orientation) is not fixed in the workcell. An example of a moving object is a box on a conveyor. Checking for and avoiding collision with such an object requires online knowledge about its position. Path changes can be both expected or unexpected. An expected path change is a change that is inherent to the process and is within known boundaries. Such change could be the result of sensory data, for example, which cause the robot to follow different paths from one cycle to the other. An unexpected path change is a change, either small or large, that occurs when the path is supposed to be the same at all times or that exceeds some boundary of an expected change. Changes that occur when the path is supposed to be constant can be the result of drifts, for example. Dramatic changes that are beyond the boundaries of the expected change can be the result of sensor failure or unhandled errors, e.g. an unsecured part on a conveyor, which is placed beyond the normal position area.
Besides that, there are numerous programming errors that can lead to collisions. These collisions can occur at validation or at normal production phases.
Collisions can also happen during teaching or retouching of points because of user errors or unexpected motions. After the points have been taught or retouched collisions can occur during validation because of unexpected behavior or programming errors. Even if the teaching/retouching phases were collision-free, collisions still can occur during normal production because of path changes or programming errors that did not manifest themselves during the earlier phases. This could happen because several unusual conditions are met at the same time.
U.S. Pat. No. 6,212,444 discloses a method concerning interference avoidance of an industrial robot. In that document, the robot manipulator and another cooperative mechanism are prevented from interfering with each other by defining common areas. One mechanism is prevented from entering the common area until the other mechanism has left it. The common work area approach to avoid collision, however, fails if the control software is not properly written, thus leading to a potentially serious collision in case of an above-mentioned programming error.
Other approaches are applied to offline programming where collision-free paths are generated for the machines (robots and other cooperative mechanisms) in the workcell. However, these methods require a priori knowledge of the robot trajectories. Furthermore, the trajectories of all machines in the workcell have to be repetitive, i.e. the trajectories must not be affected by outside sensors or overrides.
Existing robot controllers usually detect a collision after the fact. Using a dynamic model of the machine, a model motor current is determined. If the actual current exceeds the model current beyond a certain threshold, a collision is assumed to have happened and the system is shut down to minimize damage.
SUMMARY OF THE INVENTION
The present invention aims at solving the problem of robot and robot-environment collision avoidance while obviating the above-mentioned disadvantages of the prior art.
To this end, the present invention provides a method of the above-mentioned type, which regularly comprises determining a stopping time for an automatically or manually controlled robot movement on the basis of actual and past joint positions and velocities of each robot joint; forecasting a configuration of a trajectory of the robot at said stopping times; checking the predicted configuration through distance/interference algorithms for interference of robot components with components of said other objects; and stopping the robot and/or said other objects in case a collision is imminent.
In the scope of the invention, said predicted configurations are determined using said stopping times and assuming that the robot continues moving with its present acceleration starting from its present velocity and position. Thus the forecasted trajectories will in general have a speed different form zero. In this context, said configuration is referred to as stopping configuration although it will generally have a speed different form zero.
In order to prevent collisions, configurations are checked for collision not only at the present time, but at a future time that is sufficient for the machines to stop safely prior to any undesired contact.
According to a further development of this method, the robot is stopped on its path. Thus robot operation can be resumed directly from the stopping position without any further position correction or workpiece rejects. Also, stopping the machines on their paths ensures that no collisions
Cuchlinski Jr. William A.
Kuka Roboter GmbH
Marc McDieunel
McGlew and Tuttle , P.C.
LandOfFree
Method and control device for avoiding collisions between... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and control device for avoiding collisions between..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and control device for avoiding collisions between... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3217159