DE102017216093A1 - Method for parameterizing a robotic manipulator - Google Patents

Abstract

Method for the parameterization of a robotic manipulator, comprising the following method steps:
- creating a configuration file (10) in which in machine-readable form the sequence of the parameterization process is described,
wherein the configuration file (10) contains at least one reference to a utility program (12a, 12b, 12c) which is executed when the configuration file is read out by machine,
- wherein the configuration file (10) further defines at least one parameter (14a, 14b) which is read out by the utility (12a, 12b, 12c) when it is executed.

Description

The invention relates to a method for parameterizing a robotic manipulator.

Today, most robots and equipment are still programmed by trained computer scientists (experts). For each new task, a new program is written. This program is written using a textual programming language and is very specific to the task. In most cases very static conditions are assumed, which allow a high execution speed, but prohibit the proximity to a person or even interaction with him. Also, minor changes in conditions require adjustments to the program.

In order to be able to profitably use robots in small and medium-sized enterprises (SMEs) and for use in low-volume productions, there are new approaches to programming. An expert no longer develops specific programs, but rather generically designed skills. A skill is also a robot program, but it is designed for a job, such as "screwing" or "joining". The program typically has several parameters with which it can be adapted to the task.

This setting of the parameters is referred to as parameterization. A simple worker (worker) should be able to select one or more skills and parameterize them. The aim is therefore that the parameterization is as simple as possible.

Typically, a graphical user interface is used for this, which displays a parameter and prompts for the input of the desired parameter value.

In addition to the simple input of parameter values via keyboard and mouse, it is often more intuitive to use faster and easier (external) human-machine interfaces (hereinafter abbreviated to "MMI"). Examples of MMIs are speech recognition systems, compliant manipulators, joysticks, eye trackers, etc. If a skill "screws" has a parameter "hole position", for example, this value could be set by manipulating a manipulator to the hole. The parameter value is not entered in this case via a keyboard, but haptically determined by a manipulator (which can be moved freely). The measured pose of the manipulator is used as the parameter value.

One challenge now is how to integrate an MMI in the parameterization process. Here it must be determined which MMI is used for which parameter, which tasks are transferred to the user, how the user is informed about his task and the progress of the process, how it is determined which value is used for the parameter, and how an MMI is configured.

• - „Robot Programming Suite“ (RPS) von ArtiMinds
• - DESK von FRANKA EMIKA,
• - drag&bot von Fraunhofer IPA.

The following systems are known from the prior art:

• - Robot Programming Suite (RPS) by ArtiMinds
• - DESK of FRANKA EMIKA,
• - drag & offered by Fraunhofer IPA.

All systems use a manipulator as an MMI to enter positions.

These systems have the following disadvantages:

The parameterization process can not be flexibly configured, but fixed in the form of a program. If an MMI is to be replaced or supplemented, then the complete program must be rewritten. The program also defines the user interface (GUI). Thus, the parameterization process is firmly tied to the GUI. An exchange of the GUI forces a rewriting of the parameterization process. It should be noted that the GUI depends on the hardware used. If a tablet is used as the output device instead of a personal computer, the GUI usually has to be set to a different technology.

Furthermore, the systems mentioned are inflexible. Manufacturers provide a fixed set of skills, parameterization process and GUI that users can not change. For example, it is not possible for the user to integrate another MMI. For example, if a company has a 3D mouse that can theoretically also specify poses, it can not be integrated with existing systems.

The object of the invention is to provide a method for the parameterization of a robotic manipulator that has an increased flexibility.

The object is achieved according to the invention by the features of claim 1.

In the method according to the invention for the parameterization of a robotic manipulator, a configuration file is created in which machine-readable form the sequence of the parameterization process is described. For example, a machine-readable format such as JSON or YAML may be used. The configuration file contains at least one reference to a utility that is used in the parameterization process. The configuration file further defines at least one parameter for which at least one parameterization process is described. A parameterization process consists of a sequence of steps that refer to utilities.

The utility may be an existing standalone utility that is addressable via an address, particularly a URL, and that has a common known interface. This can be, for example, the utility "record object", "drop object", manipulator movement, gravity compensation, etc. One or more of these utilities can be used to read out at least one parameter value, which is then set as a parameter value for the parameterization process.

The parameterization process is thus not inventively deposited in the form of a program, but described in the form of a configuration file that is machine-readable.

After the machine readout of the configuration file, a parameterization process, namely a sequence of software steps, is executed, through which the parameterization of the skill takes place.

It is also possible to assign several parameterization processes to one parameter. The choice of which process to go through can be done by the user.

The inventive method thus allows a more flexible parameterization of a skill, since the parameterization process is no longer defined in the form of a program. For example, it is possible to replace or supplement an MMI without having to rewrite the complete program for the parameterization process. Instead of defining a pose via a hand-guided robot, a 3D mouse can be used for parameterization by exchanging the utility program (preferably with the same address) without having to make any further changes to the parameterization process.

It is preferred that information for a user is stored in the configuration file for each step, which information is displayed to the user when executing the process via a user interface, for example a display.

A utility may be a human-machine interface (MMI) that can be used to read or define a parameter that is subsequently used for the parameterization process. For example, the utility may also be an interface to a database.

It is further preferred that a utility executed on the basis of the configuration file provides feedback on its successful execution.

Furthermore, it is preferred that the next step of the parameterization process is executed only after the previous utility has reported its successful execution. If no or negative feedback is sent about the execution of a previous utility, the parameterization process is aborted with an error. This can be used to ensure that all started utilities are stopped when the program is aborted.

Furthermore, it is preferred that at least one instruction command exists for a utility that is transmitted to the utility in the parameterization process.

Such an instruction command may be, for example, the command "readout" in which the utility, upon successful confirmation, supplies a read value which is used as parameter for the parameterization process.

Furthermore, the instruction commands "Start" and "Stop" may be used, with each utility that has received a start command receiving a stop command when a utility has not been completed successfully.

It is also possible to have details of a utility, such as name, description, address, etc. centrally in the list of all utilities. In one step of the parameterization process, then only the corresponding service has to be referenced.

Furthermore, instructions to utilities can be structured in statement commands and statement parameters. Here statement parameters can further specify an instruction command. A simple instruction parameter would be about the expected unit of return value read by a utility. More complex parameters can also define which robot with which properties are addressed by the utility should. Instruction commands and instruction parameters are preferably stored for each step of a parameterization process.

Furthermore, it is possible that a process also contains special steps that modify the purely sequential process. Such special steps may define conditional jumps, temporary memories, and arithmetic operations, allowing for loops and branches within the parameterization process.

The method according to the invention thus offers the following advantages:

Separation of skill, parameterization process and GUI:

Instead of programmatically integrating the parameterization process into the tool while firmly integrating the GUI, the invention allows configuration of the parameterization process, regardless of the technology, MMI, skill, and GUI used.

Configurability of the parameterization process by end users:

The parameterization process is no longer rigidly integrated into the craft and thus in the hands of the manufacturer, but can be configured independently for each parameter. This configuration can be done by the end user, who is now able to adapt the skill to their environment and conditions.

Connection of any utility via interface description:

Instead of programmatically accessing a utility directly in the craft, a utility receives a defined interface. Any utility can be integrated as long as they provide an appropriate interface.

Correct reset of MMI in case of error:

Up to now, the manufacturer has to ensure individually for each parameterization process that MMIs are reset correctly in the event of an error. With the invention this is inherently integrated in the system and thus ensured from the outset for each parameter process.

Choice between different parameterization processes:

A parameter can be assigned several parameterisation processes, between which the user can choose. With current systems, there is always exactly one process.

In the following, preferred embodiments of the invention will be explained with reference to a figure.

The figure shows a schematic representation of an environment in which the erfindngsgemäße method can be implemented.

The figure shows the configuration file 10 , in which the sequence of the parameterization process is described in machine-readable form. When the configuration file is read out by machine, a sequence of software steps, namely the parameterization process, is executed.

The configuration file 10 defines the parameters 14a and 14b , These can be through one of the utilities 12a . 12b . 12c be read out. The utilities 12a . 12b . 12c are also through the configuration file 10 Are defined.

Furthermore, the configuration file 10 Identify information for a user displayed through a user interface, a GUI.

The following is an example of an application in which the parameter "hole pose" is set for the skill "screws". This can be done as follows:

If the user wants to determine the hole pose, the necessary electric screwdriver is automatically picked up and moved to the object. Est then the manipulator is unlocked and the user can lead the manipulator to the hole. He then confirms, whereupon the manipulator pose is read out and the cordless screwdriver is deposited. Each step is accompanied by a dialog box that provides the user with up-to-date information about execution.

The illustrated configurations can be expanded and / or modified as desired. The process is clear and can nevertheless be read out and read by legitimate systems. Other MMIs can be added to the list of services just as easily if there is an appropriate process for doing so.

The configuration file can, for example, have the following information about the parameterization process in the form of a pseudocode:

• - Objekt aufnehmen: URL = /services/pickup_object, Port = 5000
• - Objekt ablegen: URL = /services/place_object, Port = 5001
• - Manipulatorbewegung: URL = /services/move_to, Port = 5002
• - Gravitationskompensation: URL = /services/zero_gravity, Port: 5003

First of all, the available utilities are configured as follows:

• - Record object: URL = / services / pickup_object, port = 5000
• - Drop object: URL = / services / place_object, port = 5001
• - Manipulator movement: URL = / services / move_to, port = 5002
• - Gravity compensation: URL = / services / zero_gravity, port: 5003

• • Akkuschrauber greifen
  • ◯ Dienst: Objekt aufnehmen
  • ◯ Parameter: Roboter = roboter01, Objekt = Akkuschrauber, Geschwindigkeit = 0,1 m/s
  • ◯ Benutzerhinweis: Akkuschrauber wird aufgenommen
• • Bewegung zum Objekt
  • ◯ Dienst: Manipulatorbewegung
  • ◯ Parameter: Roboter = roboter01, Ziel = [Koordinate], Geschwindigkeit = 0,2 m/s
  • ◯ Benutzerhinweis: Akkuschrauber wird zum Objekt geführt
• • Lochposition durch händisches Führen des Manipulators im Gravitationskompensationsmodus eingeben
  • ◯ Dienst: Gravitationskompensation
  • ◯ Kommando: Start
  • ◯ Parameter: Roboter = roboter01
  • ◯ Benutzerhinweis: Akkuschrauber zur Lochposition führen und bestätigen
• • Pose des Manipulator auslesen
  • ◯ Dienst: Gravitationskompensation
  • ◯ Kommando: Auslesen
  • ◯ Parameter: Roboter = roboter01
  • ◯ Benutzerhinweis: Lochposition wird ausgelesen
• • Gravitationskompensationsmodus beenden
  • ◯ Dienst: Gravitationskompensation
  • ◯ Kommando: Stop
  • ◯ Parameter: Roboter = roboter01
  • ◯ Benutzerhinweis: Manipulator wird gestoppt
• • Manipulator vom Objekt entfernen
  • ◯ Dienst: Manipulatorbewegung
  • ◯ Parameter: Roboter = roboter01, Ziel = [Koordinate], Geschwindigkeit = 0,1 m/s
  • ◯ Benutzerhinweis: Akkuschrauber wird vom Objekt entfernt
• • Akkuschrauben zurücklegen
  • ◯ Dienst: Objekt ablegen
  • ◯ Parameter: Roboter = roboter01, Ziel = Ladestation, Geschwindigkeit = 0,1 m/s
  • ◯ Benutzerhinweis: Akkuschrauber wird abgelegt

The parameter "hole pose" is assigned a parameterization process. Its steps can be configured in a similar format as follows:

• • Grab the cordless screwdriver
  • ◯ Service: record object
  • ◯ Parameter: robot = robot01, object = cordless screwdriver, speed = 0.1 m / s
  • ◯ User note: The cordless screwdriver is picked up
• • Movement to the object
  • ◯ Service: Manipulator movement
  • ◯ Parameter: robot = robot01, destination = [coordinate], speed = 0.2 m / s
  • ◯ User note: The cordless screwdriver is guided to the object
• • Enter the hole position by manually guiding the manipulator in the gravity compensation mode
  • ◯ service: gravitational compensation
  • ◯ Command: Start
  • ◯ Parameter: Robot = robot01
  • ◯ User note: Guide the cordless screwdriver to the hole position and confirm
• • Read pose of manipulator
  • ◯ service: gravitational compensation
  • ◯ Command: readout
  • ◯ Parameter: Robot = robot01
  • ◯ User note: Punch position is read out
• • End gravity compensation mode
  • ◯ service: gravitational compensation
  • ◯ Command: Stop
  • ◯ Parameter: Robot = robot01
  • ◯ User note: Manipulator is stopped
• • Remove the manipulator from the object
  • ◯ Service: Manipulator movement
  • ◯ Parameter: robot = robot01, target = [coordinate], velocity = 0.1 m / s
  • ◯ User note: The cordless screwdriver is removed from the object
• • Cover the battery screws
  • ◯ Service: drop object
  • ◯ Parameter: robot = robot01, target = charging station, speed = 0.1 m / s
  • ◯ User note: The cordless screwdriver is stored

In the said parameterizing process, there exists a single step to be performed by the user, namely, the one in which the punching position is input by manually guiding the manipulator in the gravity compensating mode. The remaining steps are carried out independently.

Claims (9)

Method for the parameterization of a robotic manipulator, comprising the following method steps: - creating a configuration file (10) in which in machine-readable form the sequence of the parameterization process is described, wherein the configuration file (10) contains at least an indication of a utility (12a, 12b, 12c) used in the parameterization process, - wherein the configuration file (10) further defines at least one parameter (14a, 14b) for which at least one parameter process is described. Method according to Claim 1 , characterized in that the utility (12a, 12b, 12c) is an existing stand-alone utility that is addressable via an address, in particular a URL, and that has a common known interface. Method according to Claim 1 or 2 , characterized in that after the machine readout of the configuration file (10), a parameterization process, namely a sequence of software steps is performed, through which the parameterization of the robotic manipulator takes place. Method according to Claim 3 , characterized in that in the configuration file (10) information for a user are stored, which are displayed to the user during execution of the parameterization process via a user interface (16a, 16b). Method according to one of Claims 1 to 4 , characterized in that a utility (12a, 12b, 12c) executed on the basis of the configuration file (10) transmits a response for successful execution. Method according to Claim 5 Characterized in that the next step of the Parametrierungsprozesses is performed only after the previous utility (12a, 12b, 12c) has reported a successful execution, wherein, if no or a negative feedback on the execution of a preceding service program 12a, 12b, 12c ), the parameterization process is aborted with an error. Method according to one of Claims 1 to 6 , characterized in that for a utility (12a, 12, 12c) at least one instruction command exists that is transmitted to the utility (12a, 12b, 12c) from the configuration file (10). Method according to one of Claims 1 to 7 , characterized in that an instruction command is "read" in which the utility (12a, 12b, 12c), upon successful completion of a return, provides a read value used as parameter for the parameterization process. Method according to one of Claims 1 to 8th characterized in that an instruction command "start" and an instruction command is "stop", wherein each utility (12a, 12b, 12c) having received a start command receives a stop command if a utility (12a, 12b, 12c) does not successfully completed.

Images