Robot, control device for a robot, and method for operating a robot

Abstract

The invention relates to a robot, a robot control device, and a method for operating a robot. The robot includes an arm having a plurality of members following one after the other, an attaching device for attaching an end effector and drives for moving the members, and a control device connected to the drives. In another aspect, a computer program running on the control device issues a command for the robot arm to carry out an application step. At least one abort condition of the command from a plurality of abort conditions is detected, the execution of the application step is aborted on the basis of the detected abort condition, and simultaneously with the detection of the abort condition information is passed to the computer program about the abort condition on the basis of which the execution of the application step was aborted.

Claims

1. A method for operating a robot, which has a robot arm having a plurality of links following one after the other, an attaching device for attaching an end effector and drives for moving the links, and a control device connected to the drives, having the following procedural steps: using a computer program running on the control device, initiation of a command on the basis of which the robot arm, controlled by the control device, begins to carry out an application step, detection of an abort condition of the command from a plurality of abort conditions, wherein the abort condition is the attainment of a maximum force acting on the end effector, a detection of an obstacle and/or an expiration of a prescribed time period, aborting of the execution of the application step on the basis of the detected abort condition while continuing to run the computer program until an additional command is initiated, in response to the detection of the abort condition, conveying to the computer program information about the nature of the abort condition on the basis of which the execution of the application step was aborted, determining with the computer program an additional command to be initiated on the basis of the information about the nature of the abort condition, and acyclically evaluating at least one abort condition, wherein the abort condition in question is assigned to an interrupt service routine and is triggered on the basis of events and/or sensors.

2. The method according to claim 1, further comprising conveying to the computer program an identifier assigned to the detected abort condition.

3. The method according to claim 1, wherein the additional command is assigned to the detected abort condition, the method further comprising, in response to the information about the detected abort condition, initiating the additional command to actuate the robot arm by means of the control device.

4. The method according to claim 3, wherein each of the abort conditions of the plurality of abort conditions has a unique identifier assigned to it, which is conveyed to the computer program upon detection of the abort condition in question.

5. The method according to claim 1, wherein at least one of the abort conditions is produced with corresponding information from a software module.

6. The method according to claim 1, wherein at least one of the plurality of abort conditions has a software module assigned to it, which passes to the computer program information about its abort condition upon detection of the abort condition in question.

7. An apparatus for operating a robot, comprising: a control device that is set up to operate a robot arm having a plurality of links following one after the other, an attaching device for attaching an end effector, and drives for moving the members, wherein the control device operates the robot arm according to the method of claim 1.

8. The apparatus of claim 7, further comprising: a robot arm that has a plurality of links following one after the other, an attaching device for attaching an end effector, and drives for moving the members, wherein the control device is connected to the drives for moving the robot arm.

9. The method according to claim 1, wherein the information about the abort condition includes information that characterizes the nature of the abort condition.

10. A method for operating a robot, the robot including a robot arm having a plurality of links following one after the other, an attaching device for attaching an end effector, drives for moving the links, and a control device connected to the drives, the method comprising: using a computer program running on the control device, initiating a command on the basis of which the robot arm, controlled by the control device, begins to carry out an application step; detecting an abort condition of the command from a plurality of abort conditions, wherein the abort condition is the attainment of a maximum force acting on the end effector, a detection of an obstacle and/or an expiration of a prescribed time period; aborting the execution of the application step on the basis of the detected abort condition while continuing to run the computer program until an additional command is initiated; in response to the detection of the abort condition, conveying to the computer program information identifying the nature of the abort condition on the basis of which the execution of the application step was aborted; classifying the abort condition with the computer program as being one of the plurality of abort conditions on the basis of the information about the nature of the abort condition; and acyclically evaluating at least one abort condition, wherein the abort condition in question is assigned to an interrupt service routine and is triggered on the basis of events and/or sensors.

Description

(1) One example of an exemplary embodiment of the invention is depicted in the attached schematic drawings. The figures show the following:

(2) FIG. 1 a robot with a robot arm and a control device, and

(3) FIG. 2 an end effector in the form of a gripper, which grips an object and is attached to an attaching device of the robot arm.

(4) FIG. 1 shows a robot R, which has a robot arm M and a control device S. The robot arm M represents essentially the movable part of the robot R, and includes a plurality of members 1 following one after the other, which are connected with each other by means of joints 2. At one of its ends the robot arm M has an attaching device 3 for example in the form of a flange, to which for example an end effector in the form of a gripper 4 may be attached. The gripper 4 has for example gripping jaws 5, by means of which the gripper 4 is able to hold an object 6, so that the latter can be moved by means of the robot R. The gripper 4 with the gripped object 6, the attaching device 3 and parts of the robot arm M are shown in greater detail in FIG. 2.

(5) The robot arm M also has drives, not shown in greater detail, connected to the control device S, by means of which the members 1 can be moved relative to each other in reference to axes assigned to the joints 2.

(6) The drives are for example electric drives, and are actuated by the control device S when the robot is in automatic operation, so that the attaching device 3 or a so-called tool center point of the robot R executes a predefined motion automatically. To this end, a corresponding user program runs on the control device S. The control device S may be defined in particular in such a way that it regulates the drives during automatic operation. The gripper 4 is also connected to the control device S, so that the latter is able to control a gripping and releasing of the object 6.

(7) In the case of the present exemplary embodiment, the gripper 4 has a force/torque sensor 7 and a camera 8, which are likewise connected to the control device S, so that the latter has access to signals produced by the force/torque sensor 7 and by the camera 8.

(8) In the case of the present exemplary embodiment, the user program is designed so that it gives a command which is intended to execute an application step of the current application of the robot R. Furthermore, the control device S or the user program running on it is designed so that this command is active until at least one of a plurality of prescribed abort conditions is fulfilled.

(9) In the case of the present exemplary embodiment, the abort conditions may be for example the following.

(10) A first abort condition is the attainment of a minimum force F.sub.min acting on the object 6 or on the gripper 4, for example 10 N. The force acting on the object 6 or on the gripper 4 is ascertained in particular using the force/torque sensor 7 and is evaluated by the control device S.

(11) A second abort condition is the detection of an obstacle 9, with which the gripper 4 or the object 6 may potentially collide. The obstacle 9 may be detected by means of image records recorded by the camera 8, which are evaluated for example by the control device S.

(12) A third abort condition is the expiration of a prescribed period of time T, for example 55 seconds, starting from the beginning of the command.

(13) In the case of the present exemplary embodiment, an identifier for example in the form of a return value is assigned to each of the abort conditions.

(14) In the case of the present exemplary embodiment, the control device S is set up or the user program running on the control device S is designed so that when at least one of the abort conditions is present the control device S not only halts the command, but a notification or indication about the existing abort condition is also conveyed to the control device S for example in the form of the associated identifier, for example in the form of the corresponding return value. Based on this information, the application running on the control device S, or the user program running on the control device S, is able to decide directly what action is to be taken based on the specific abort condition, without ascertaining the cause of the abort again.

(15) This can be programmed for example using the following pseudo-codes: Return_value=robot_command( . . . , 1:=force>10 N, 2:=object_detected=true, 3:=running_time>55 sec.) call function(return_value)

(16) For example, if the cause of the abort was the detection of the obstacle 9, i.e., the second abort condition, then function (2) is called. Now the abort causes are returned, which means for example that the cause of the abort no longer has to be ascertained by the user.

(17) In the case of the present exemplary embodiment, the control device S or the user program running on the control device S is designed so that in addition the in particular user-defined abort conditions are augmented by default abort conditions. These default abort conditions are defined for example by participating control modules, i.e., on the basis of the force ascertained by means of the force/torque sensor 7 and of the obstacle 9 possibly detected by means of the camera 8.

(18) In the case of the present exemplary embodiment, the user program may be designed is such a way that controlling and regulating functionalities are divided up or encapsulated in particular in standardized modules, i.e., in software modules. Each module can have a module-specific abort condition, which is defined in particular by the module developer. In this case the possibility exists to generate the parameterizing of the abort condition automatically from the particular module task. The module-specific abort condition monitors for example in general internal module states. The result of these module abort conditions may be OR-linked for example with user command abort conditions. The module can thereby trigger the end of a command independently of the user abort conditions. In addition, the module may have a description of the reason for the occurrence of the abort condition, which is added to the command return value. That can make it easier to ascertain the reason for stopping the command. With this solution, the user is no longer responsible for having to take into account module-specific properties in the user abort condition.

(19) In the case of the present exemplary embodiment, for example, a force module assigned to the force/torque sensor 7, an object detection module assigned to the camera 8 or a time module assigned to the time period T can deliver their own abort criteria. In the system these modules, which are implemented in particular as software modules, each have their own unambiguous identifier. The latter is returned as the cause of the abort. In the case of the present exemplary embodiment, this may be realized as follows:

(20) The force module has for example the identifier K20, the object detection module has the identifier K23 and the time module has the identifier K18. Based on the identifier conveyed, the application running on the control device S or the user program running on the control device S can decide directly what action is to be performed based on the specific abort condition, without ascertaining the reason for the abort again. This can be programmed by means of the following pseudocodes. Return_value=robot_command( . . . , 1:=force>10 N, 2:=object_detected=true, 3:=running_time>55 sec.) call function (return value).

(21) Now if the object detection module interrupted the command, the function (K23) is called.

(22) In addition, it can be provided that default abort conditions are defined in the system configuration of the control device S, which are OR-linked to the abort conditions of the application defined by the user. They then apply system-wide. As a result, it is no longer necessary to specify obligatory aborts explicitly.

(23) Preferably, the default abort condition cannot and may not be changed at system running time, i.e., by the application. That ensures that the abort condition which is effectively utilized does not depend on the command history.

(24) Dedicated acyclical abort conditions may also be specified. These are swapped out for example into an interrupt service routine of the control device S. The associated interrupt is triggered for example by events or sensors which are used in the abort condition. In this way, this part of the abort condition is not evaluated cyclically, but only in the case of signal changes or special events. The result can in turn be OR-linked to the command abort condition. An advantage of this solution is that the program sequence of the robot program or user program is not interrupted; that is, the program developer does not have to swap out parts of his application into an interrupt service routine or program them explicitly. It is not the application, but the command that is interrupted.