EP3965999A1 - Verfahren und system zur bestimmung von optimierten programmparametern für ein roboterprogramm - Google Patents

Verfahren und system zur bestimmung von optimierten programmparametern für ein roboterprogramm

Info

Publication number
EP3965999A1
EP3965999A1 EP21739967.4A EP21739967A EP3965999A1 EP 3965999 A1 EP3965999 A1 EP 3965999A1 EP 21739967 A EP21739967 A EP 21739967A EP 3965999 A1 EP3965999 A1 EP 3965999A1
Authority
EP
European Patent Office
Prior art keywords
program
robot
parameters
critical
optimized
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP21739967.4A
Other languages
English (en)
French (fr)
Inventor
Rainer JAEKEL
Darko Katic
Benjamin Alt
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Artiminds Robotics GmbH
Original Assignee
Artiminds Robotics GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Artiminds Robotics GmbH filed Critical Artiminds Robotics GmbH
Publication of EP3965999A1 publication Critical patent/EP3965999A1/de
Pending legal-status Critical Current

Links

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B25—HAND TOOLS; PORTABLE POWER-DRIVEN TOOLS; MANIPULATORS
    • B25J—MANIPULATORS; CHAMBERS PROVIDED WITH MANIPULATION DEVICES
    • B25J9/00—Programme-controlled manipulators
    • B25J9/16—Programme controls
    • B25J9/1656—Programme controls characterised by programming, planning systems for manipulators
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B25—HAND TOOLS; PORTABLE POWER-DRIVEN TOOLS; MANIPULATORS
    • B25J—MANIPULATORS; CHAMBERS PROVIDED WITH MANIPULATION DEVICES
    • B25J9/00—Programme-controlled manipulators
    • B25J9/16—Programme controls
    • B25J9/1602—Programme controls characterised by the control system, structure, architecture
    • B25J9/161—Hardware, e.g. neural networks, fuzzy logic, interfaces, processor
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B25—HAND TOOLS; PORTABLE POWER-DRIVEN TOOLS; MANIPULATORS
    • B25J—MANIPULATORS; CHAMBERS PROVIDED WITH MANIPULATION DEVICES
    • B25J9/00—Programme-controlled manipulators
    • B25J9/16—Programme controls
    • B25J9/1628—Programme controls characterised by the control loop
    • B25J9/163—Programme controls characterised by the control loop learning, adaptive, model based, rule based expert control
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/39—Robotics, robotics to robotics hand
    • G05B2219/39298—Trajectory learning
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/40—Robotics, robotics mapping to robotics vision
    • G05B2219/40392—Programming, visual robot programming language
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/40—Robotics, robotics mapping to robotics vision
    • G05B2219/40395—Compose movement with primitive movement segments from database

Definitions

  • the invention relates to a method and system for determining optimized program parameters for a robot program, the robot program being used to control a robot with a manipulator, preferably in a robot cell.
  • industrial robots are used in particular for solving complex manipulation and assembly tasks and for surface treatment when the workpieces to be machined or the application tasks to be performed show a degree of variability.
  • the ability of industrial robot arms to approach almost any tool or workpiece position and orientation within their workspace, in combination with suitable end effectors, enables the solution of different application tasks or the processing of different workpiece variants within a robot cell.
  • Manufacturing cells with industrial robots are traditionally programmed using text, with poses or partial movements being taught in for the initial parameterization using a teach-in process using so-called teach pendants.
  • Numerous manufacturer-specific and manufacturer-independent commercial products facilitate the offline programming of robot cells through the automatic generation of robot code and semi-automatic path generation using CAD models of the robot cell and the workpieces to be machined (“CAD to Path”).
  • Block-based programming systems or programming software such as the ArtiMinds Robot Programming Suite (RPS), RoboDK or drag&bot simplify robot programming by encapsulating atomic motion primitives in abstract program blocks that can be combined to form complex manipulation sequences.
  • Symbolic, parameterizable program representations are an established practice in service and industrial robotics.
  • Task models usually consist of atomic, parameterizable action primitives, which can be combined into complex action sequences by control flow and logic primitives and translated into sequences of specific robot movements.
  • Generalized manipulation strategies and their implementation such as the ArtiMinds Task Model, represent action primitives as groups of possibly learned constraints (conditions) in joint angle or Cartesian space, from which movements are generated that meet these constraints. For example, reference is made to DE 10 2015 204 641 A1.
  • DSLs Domain-Specific Languages
  • Some platforms such as MindSphere or Nexeed enable the optimization and adjustment of certain process control parameters in order to optimize parameters such as throughput or cycle time, but operate at the macro level, so that fine-tuning of program parts of a robot program, for example, is not possible. Since the behavior of a robot is specified in software, the development and maintenance effort of robot cells is shifted away from the hardware to the software.
  • a robust solution to complex manipulation tasks with industrial robots depends heavily on task-specific program parameters such as speed, acceleration, force specifications or target points, which must be precisely matched to the task to be solved, the geometry and physical properties of the robot cell and the workpieces to be machined . Especially when commissioning new robot cells, fine-tuning the program parameters is very time-consuming, requires highly specialized expert knowledge and delays the productive operation of the robot cell.
  • the present invention is therefore based on the object of designing and developing a method and a system for determining optimized program parameters for a robot program of the type mentioned at the outset in such a way that finding optimized program parameters for the robot program is simplified or improved.
  • a method for determining optimized program parameters for a robot program is specified, with the robot program being used to control a robot with a manipulator, preferably in a robot cell, with the method comprising the following steps:
  • the robot program being formed from program modules that can be configured via program parameters, and initial program parameters being generated for the program modules of the robot program;
  • a system for determining optimized program parameters for a robot program is specified, the robot program being used to control a robot with a manipulator, preferably in a robot cell.
  • This system comprises: a component-based graphical programming system for creating a robot program based on user input, the robot program being formed from program components that can be configured via program parameters, and initial program parameters for the program components of the robot program being able to be generated; an interface for selecting one or more critical program modules, it being possible to define program parameters that can be optimized for the critical program modules; an exploration module for exploring a parameter space in relation to the program parameters that can be optimized, the robot program being executed multiple times, the parameter space being scanned for the critical program modules and trajectories of the robot being recorded, so that training data are available for the critical program modules ; a learning module for generating building block representatives for the critical program building blocks of the robot program based on the training data collected in the exploration phase, with a building block representative representing a system model that, in
  • a robot program is first generated using a component-based graphic programming system based on user inputs.
  • the robot program is formed from program modules, with the program modules being parameterizable via program parameters.
  • the robot program therefore represents a semi-symbolic robot program. Furthermore, initial and thus preliminary program parameters for the program modules of the robot program are generated or specified.
  • one or more critical program modules can then be selected using an interface that is provided, it being possible to define program parameters that can be optimized for the critical program modules.
  • an automatic and stochastic exploration of a parameter space takes place in relation to the program parameters that can be optimized.
  • the robot program is executed several times or repeatedly, with an automatic see scanning of the parameter space for the critical program modules is carried out and the resulting trajectories of the robot are recorded. Training data can thus be collected for each execution of the robot program for the critical program modules.
  • a component representative here is a system model that, in the form of a differentiable function, maps a specified state of the robot measured or determined in the exploration phase and specified program parameters to a predicted - i.e. an expected - trajectory.
  • optimized program parameters for the critical program modules of the robot program are determined in an inference phase.
  • optimizable program parameters of the building block representatives are iteratively optimized with regard to a predetermined target function by means of a gradient-based optimization method using the previously generated building block representatives.
  • an optimal parameter vector is obtained for each critical building block.
  • the optimized program parameters can be automatically transferred to the robot program. In this way, a robot program can be achieved with program parameters that are optimal with regard to a specified target function.
  • a "block-based graphical programming system” can - in particular within the scope of the claims and preferably within the scope of the description - be understood as a programming system or programming software that allows encapsulation of atomic motion primitives in abstract program blocks, the program blocks to complex manipulation sequences zen can be combined.
  • the ArtiMinds Robot Programming Suite (RPS), RoboDK or drag&bot are just examples of possible building block-based programming systems.
  • a "semi-symbolic robot program” can - in particular within the scope of the claims and preferably within the scope of the description - be understood as a robot program that has a symbolic structure (composed of individual program modules), whose components (the program modules ) are variable in their behavior, since the exact behavior of the blocks still depends on the parameterization).
  • Discrete program blocks which can each be parameterized, have both properties and can therefore be viewed as semi-symbolic.
  • a block-based graphical programming system can generate a semi-symbolic robot program.
  • a “program module” can be understood as the smallest user-configurable unit of a symbolic or semi-symbolic robot program.
  • the program module represents a predefined action of the robot.
  • Program blocks can be sequentially combined to form complex robot programs.
  • Program blocks can be parameterized, i.e. they accept a vector of parameters whose values can be specified by the robot programmer when creating the robot program.
  • Each program block has exactly one type, which determines the action that the program block represents. Examples of program blocks are “gripping”, “point-to-point movement”, “contact travel (relative)”, “arc travel”, “spiral search (relative)”, “torque-controlled joining”, “force-controlled pressing”, “palletizing” etc.
  • a “critical program module” can be understood—particularly within the scope of the claims and preferably within the scope of the description—as a program module for which optimized parameters are to be determined.
  • a "block representative" can - in particular within the scope of the claims and preferably within the scope of the description - a system model for a Program block to be understood, which models the behavior of the program block during its execution.
  • a block representative in the sense of the definition of a system model can map a vector of input parameters and the system state at the time of execution to the trajectory to be expected during execution, with the system in the sense of the definition of a system model including the robot arm and possibly the Environment of the robot and possibly the objects manipulated during the execution of the program module.
  • a “system mode” can be understood—particularly in the context of the claims and preferably in the context of the description—as a mathematical model that approximates the behavior of a system in a simplified manner.
  • a "system modeN” can be defined as a mathematical function / that, given the input parameters x and the system state p, returns the expected trajectory ⁇ . / thus implicitly contains the program logic (the translation of x into control commands for the robot by the robot program), the kinematics and dynamics of the robot, and the physical properties of the environment.
  • trajectory can be understood as a sequence of vectors sampled at a fixed sampling interval, which can contain information about the state of the robot and optionally also about its surroundings.
  • trajectories for each magazine can contain one or more of the following information:
  • a status code ( per foi g ) between 0 and 1, which indicates whether an error occurred during the execution of the movement, eg whether the force specification was violated in a force-controlled movement.
  • Parameter domains can advantageously be specified for the program parameters that can be optimized for the critical program modules, with the program parameters that can be optimized being optimized via the parameter domains.
  • a parameter domain represents a permissible range of values for the program parameter that can be optimized.
  • a permissible range of values or a parameter domain is expediently provided for each program parameter that can be optimized.
  • the parameter domains for the program parameters of the critical program modules that can be optimized can be specified and/or can be specified or set. Accordingly, a domain can also be preset. This means that the parameter domain for a program parameter could already be specified by the underlying system. Furthermore, it is conceivable that a robot programmer/user selects a parameter domain for the program parameters of the critical program modules to be optimized, via which optimization is to be carried out. This parameter domain is application-specific and should be selected to be sufficiently narrow so that safety requirements for the manufacturing process and minimum requirements for quality and cycle times are met.
  • the program parameters that can be optimized can be sampled from their respective parameter domains in the exploration phase for scanning the parameter space. That means the optimal program parameters that can be measured are randomly selected as a random sample from the parameter domain. It is conceivable that the program parameters that can be optimized are sampled in a uniformly distributed manner, ie a uniformly distributed sampling is carried out. This provides the advantage that any sampling errors are widely distributed over the sampling space. Uniform sampling provides enough randomness to avoid systematic undersampling while ensuring uniform coverage of the parameter space. Furthermore, it is conceivable that the program parameters that can be optimized are sampled adaptively. Adaptive sampling can therefore be carried out and samples expediently there or in the areas where information is still required.
  • the robot program can advantageously be stored in a serialized format, preferably in a database, in such a way that the format enables the robot program or its program modules to be reconstructed and parameterized.
  • the format can include a sequential execution order of the program modules, types of the program modules, IDs of the program modules, constant program parameters and/or program parameters that can be optimized.
  • the format and the stored data thus allow particularly efficient field handling and implementation to be achieved. Further advantages of these features include the possibility of using the stored program structure, building block types and parameters to generate the overall system models, consisting of sequences of building block representatives for the building blocks contained in the program structure, fully automatically.
  • Another advantage is the possibility of reusing data from earlier explorations (possibly for other robot programs) in parts for training new block representatives (e.g. for execution in changed environments, etc.) for blocks of the same block type at any later point in time , since the specified format enables block types and parameters to be read out later.
  • a resulting, scanned trajectory can be stored in such a way that each data point of the trajectory can be clearly assigned an associated program module and a parameterization of the associated program module at the time of the respective execution .
  • This makes possible particularly efficient handling and implementation of the data stored with the trajectory.
  • One advantage of this format is the possibility of using the stored data again later at any later point in time for training new block representatives of the same type, since the partial trajectories for program blocks of specific types can be assigned directly and extracted from the overall trajectory.
  • the robot program can be executed automatically, with at least 100 executions, preferably at least 1000 executions, of the robot program being carried out to obtain the training data.
  • the automated execution of the robot program has the advantage that no human resources are tied up during the exploration phase and enables the time- and resource-efficient collection of real training data.
  • the number of executions of the robot program during the exploration phase has an advantageous effect on the quality of the program parameters optimized in the inference phase, since a higher number of training data means a finer sampling of the parameter space and the system behavior, whereby the neuronal Networks can learn to approximate the system behavior with different parameters more robustly and precisely. Since the block representatives form the basis for the system for optimizing the program parameters, generally optimized parameter sets that come closer to the globally optimal parameterization can be expected with larger amounts of training data.
  • the training data collected in the exploration phase for each execution of the robot program can include a parameterization, in particular constant and/or optimizable program parameters, of the critical program modules and a respectively resulting, sampled trajectory of the critical program modules.
  • the block representatives can thus be generated in the learning phase.
  • the program parameters that are randomly sampled in the exploration phase, ie, randomly generated, can be optimized and stored as part of the training data and associated with the execution of the robot program.
  • the joint storage of program parameters and trajectories simplifies the implementation significantly, since only one database or one storage format needs to be connected.
  • the training data collected in the exploration phase can also include an ID (that is, an identifier or identifier) and/or a status code for each executed program module.
  • the ID can be used to assign a building block and a parameter to the building block and a trajectory to the building block.
  • the status code can be used to store success/failure of execution and can therefore be an important part of the program block semantics for the block representatives to learn.
  • the error rate can be minimized as a target function for the optimization. Consequently, the spectrum of possible, usable target functions is expanded.
  • learnable block representatives can first be generated in the learning phase for the critical program blocks, with the learnable block representatives being trained with the training data from the exploration phase, and then as learned block representatives system models for the associated critical program blocks - display an encapsulated sub-process.
  • This enables the simple software implementation of block representatives as object-oriented classes (there is a (software) class for each type of program block, which implements the trajectory generator for this type of block, the architecture of the neural network and the necessary for the training logic included).
  • These classes only have to be developed once (e.g. as part of a software product for graphical robot programming) and can then be repeatedly instantiated to concrete building block representatives whose neural network is then trained.
  • the building block representatives can advantageously include a recurrent neural network.
  • This provides universal applicability. Since the recurrent neural network uses a deep neural network as a system model, the procedure described when creating the model does not make any assumptions about the nature (e.g. parametric distribution, normal distribution, linearity) of the input and output data and is therefore applicable in all manufacturing domains and in principle for all building block types can be used. Since no further requirements are placed on the target function apart from differentiability, any target functions are conceivable. The procedure is can therefore be used in any application domains such as assembly, surface processing or handling and enables the optimization of robot programs with regard to any process key figures or quality criteria.
  • an analytical trajectory generator which is expediently implemented in a differentiable manner, can be connected upstream of the recurrent neural network.
  • the analytical trajectory generator is designed to generate a prior trajectory. Since long, finely sampled trajectories in particular contain a lot of redundant information and large sequence lengths can make the learning problem significantly more difficult when predicting with neural networks, this is counteracted by an analytical trajectory generator is connected upstream of the neural network. This generates a prior trajectory.
  • the trajectory generator can consist of a differentiable implementation of an offline robot simulator.
  • Orocos KDL https://www.orocos.org/kdl
  • Movelt https://moveit.ros.org/
  • the algorithms implemented there for motion planning can be converted into differentiable calculation graphs.
  • this transfer can be carried out by re-implementing the planning algorithms using the software library PyTorch (https://pytorch.org/), which guarantees the ability to differentiate.
  • the prior trajectory can correspond to a generic execution of the program block without considering the environment, ie in an artificial space with zero forces and under idealized robot kinematics and dynamics, starting from a given initial state.
  • This strong prior can be combined with the block parameters to form an augmented input sequence for the neural network.
  • the network can then be trained to predict the residual between the prior and posterior (ie actually measured) trajectory and the probability of success of the module execution result in block parameters.
  • Simplifying the learning problem in neural network training by introducing strong priors is established practice. By using strong priors, the need for training data can be significantly reduced by an order of magnitude will. This effect is particularly striking for long trajectories or trajectories with strong determinism.
  • the use of a differentiably implemented analytical generator as strong priors is therefore particularly advantageous.
  • the target function can advantageously be defined in such a way that the target function maps a trajectory onto a rational number and that the target function can be differentiated according to the trajectory.
  • the use of a uniform function signature for the objective function allows the easy exchange of objective functions without having to adapt the optimization algorithm.
  • the proposed signature is sufficiently simple (objective function as an evaluation of a trajectory with a numerical value) to ensure simple implementation, but at the same time allows the implementation of almost any objective function.
  • the differentiability of the target function according to the trajectory enables the use of gradient-based optimization methods for the parameter inference, which converge in a targeted manner in the direction of at least local optima by considering the gradient information and therefore converge significantly faster for many classes of target functions than non- gradient-based optimizers.
  • the target function can advantageously include a predefined function, a parametric function and/or a neural network.
  • a predefined function can relate to classic process parameters such as cycle time or path length, which output a variable that is to be minimized.
  • Parametric functions can include predefined functions that have additional parameters that can be set by the user, if necessary. Examples are distance functions to default values such as contact forces, tightening torques or Euclidean target poses. Neural networks can also be used as differentiable function approxators for complex target functions.
  • Examples of simple target functions that map process parameters are cycle time, path length and/or error rate.
  • Other more complex types of target functions can, for example, relate to compliance with force limits, force minimization with simultaneous cycle time minimization, increase in precision (e.g. in the case of stochastic position deviations of workpieces), minimization of moments, specification of certain force or moment curves, etc.
  • the target function can advantageously include a function based on force measurement.
  • the predicted trajectory is evaluated at least in part on the basis of the predicted forces and moments. This is particularly advantageous since the optimization of program parameters with regard to optimality criteria defined via forces is very difficult for human programmers, since the relationships between program parameters and the resulting forces during program execution are difficult to calculate or to understand by humans are.
  • a critical subsequence of the robot program can advantageously be selected with the interface for selecting one or more critical program modules, with the critical subsequence comprising several critical program modules.
  • the block representatives of the several critical program blocks can be combined to form a differentiable overall system model.
  • the overall system model maps the program parameters of the critical sub-sequence to a combined trajectory, so that for a coherent sub-sequence of critical program modules the optimizable program parameters are optimized with regard to the target function.
  • This enables holistic parameter optimization.
  • the program parameters of related program block sequences can be optimized together. This offers added value compared to local optimization at the building block level, since interactions with the environment across building block boundaries are considered during optimization. In particular, contradictory parameter configurations between program parts can be automatically balanced against one another.
  • input data, procedure and output data can be specified as follows:
  • the result is a robot program with optimal or optimized parameters with regard to a specified target function.
  • Advantageous embodiments of the invention can provide a method and a corresponding system for the fully automatic inference of optimized program parameters for industrial robots, which during the programming, commissioning and maintenance phases of robot cells, robot programmers or factory workers allow the parameters of complex robot programs in the presence of To optimize process and workpiece variances data-driven and automatically to cycle time and quality specifications.
  • This includes a method or a system according to an exemplary embodiment of the invention, components or modules or units that are used for automated exploration of the parameter space, modeling, specification of target functions and inference of optimal/optimized parameters.
  • a robot program with optimized parameters can be achieved and thus a robot cell with higher throughput, higher production quality or lower rejects.
  • an exemplary embodiment of the invention enables a form of process optimization based on real measured data.
  • exemplary embodiments can enable process optimization with regard to target forces or moments and the dynamic properties of the movements, since the learned system models can predict the force curves of the interaction of the specific robot in the specific environment with the specific workpieces present.
  • Known methods for process optimization from the state of the art do not or only to a limited extent consider the actually occurring forces and moments and require well-founded expert knowledge or manual trial and error.
  • - Holistic parameter optimization The parameters of related program block sequences can be optimized together. This offers added value compared to local optimization at the building block level, since interactions with the environment across building block boundaries are considered during optimization.
  • contradictory parameter configurations between program parts of the robot program can be automatically balanced against one another. This is the case, for example, when increasing the speed of a movement reduces the probability of success of a subsequent movement, for example by generating vibrations or bending pins during contact runs.
  • This holistic approach to the optimization of program parameters is of considerable advantage in industrial robotics.
  • the method according to the embodiment does not make any assumptions about the nature (eg parametric distribution, normal distribution, linearity) of the input and output data when creating the model and can therefore be used in all production domains and, in principle, for all types of components. Since no further requirements are placed on the target function apart from differentiability, any target functions are conceivable.
  • the method according to the embodiment of the Finding can thus be used in any application domains such as assembly, surface processing or handling and enables the optimization of robot programs with regard to any process key figures or quality criteria.
  • FIG. 1 shows an activity diagram for a method for determining optimized program parameters for a robot program according to an exemplary embodiment of the invention
  • FIG. 2 shows an additional activity diagram for the exemplary embodiment according to FIG. 1, the exploration phase indicated in FIG. 1 being illustrated,
  • FIG. 3 shows an exemplary robot program for a force-controlled spiral search, with the critical part program being solidly framed,
  • 5 shows a schematic view of an exemplary system architecture for a system for determining optimized program parameters for a robot program according to an exemplary embodiment of the invention
  • 6 shows a schematic representation of the database schema implemented in an exemplary reference implementation for a system or a method according to an exemplary embodiment of the invention
  • FIG. 8 shows a schematic representation of a differentiable program module according to an embodiment of the invention
  • FIG. 10 shows a recurrent network architecture for an embodiment of the invention.
  • FIG. 1 and FIG. 2 show an activity diagram for a method for determining optimized program parameters for a robot program according to an exemplary embodiment of the invention.
  • the method according to an exemplary embodiment of the invention has different characteristics or possible applications in the programming, commissioning and maintenance phases of production systems or robot cells.
  • 1 and FIG. 2 show an overview of the procedural steps of the exemplary embodiment, including optional procedural steps that can be skipped depending on the form.
  • the method according to the exemplary embodiment for the programming, commissioning and maintenance phases is described below.
  • the robot programmer creates a robot program from parameterizable program modules (motion templates), which depict the atomic movements of the robot.
  • the robot program consists of a sequence of any force- or position-controlled program modules.
  • the sequence of program blocks maps the steps necessary to solve the application task.
  • FIG. 3 shows a schematic representation of an exemplary semi-symbolic robot program 1 for force-controlled spiral search.
  • the critical subprogram 2 or the critical program modules 3 and 4 of the robot program 1 are solidly framed in FIG.
  • FIG. 4 shows a schematic representation of an exemplary semi-symbolic robot program 5 for force-controlled contact travel.
  • the critical subprogram 6 or the critical program modules 7 and 8 of the robot program 5 are solidly framed in FIG.
  • the execution semantics of a block of the "Linear movement" type 3 or 7 can be described as follows: given a target pose and a speed v and acceleration a, move the robot in such a way that the tool Center point (tool coordinate system of the robot) describes a linear path in Cartesian space from the current tool pose to the target pose with the specified speed and acceleration.
  • the execution semantics of "Contact travel (relative)" 8 can be described as follows: given a movement specification relative to the current position of the tool coordinate system of the robot (e.g. "1 centimeter translation in z-direction and 3° Rotation around the X-axis"), a force specification, which specifies the contact force along the Z-axis of the tool coordinate system, as well as a speed v and acceleration a, move the robot on a linear path in Cartesian space according to the motion specification and with the specified acceleration and speed until the specified force is reached would. The execution of the movement is considered successful if the force target is reached (contact made), otherwise it is considered to have failed.
  • a movement specification relative to the current position of the tool coordinate system of the robot e.g. "1 centimeter translation in z-direction and 3° Rotation around the X-axis”
  • a force specification which specifies the contact force along the Z-axis of the tool coordinate system, as well as a speed v and acceleration a
  • a robot programmer can determine the initial parameters of the program blocks manually using common methods (teach-in, CAD to path, ...) in order to approximate the application task (possibly violating the specified cycle times and quality requirements).
  • the robot programmer uses a method according to an exemplary embodiment of the invention for the automatic optimization of program parameters in order to meet cycle time specifications and quality requirements.
  • the critical part program 2 consists of the sequence ["Linear movement", “Spiral search (relative)"], since the parameters of the linear movement (in particular its target pose) fundamentally influence the position and orientation of the spiral search ( see Fig. 3).
  • the critical subprogram 6 consists of the sequence ["Linear movement", “Contact run (relative)"], since the Z coordinate of the target pose of the linear movement in particular fundamentally influences the expected length of the contact run ( see Fig. 4).
  • Program parameters of a program module can either be input (target poses, target forces, etc.) or intrinsic parameters (velocity, acceleration). Both types of parameters can be optimized.
  • the expected scatter of the hole positions is typically in the millimeter range, so the limits for the expansion and the coil spacing of the spiral are defined accordingly.
  • the domain of the Tait-Bryan z-component of the target pose of the linear motion is [0, 180°] due to the approximate point symmetry of the spiral (see Fig. 3).
  • the status code identifies whether the executed action was completed successfully. Force-controlled travel to contact, for example, ends successfully when contact has been made and the contact force is within a set tolerance range.
  • the randomly generated program parameters are stored in the database and associated with the program execution.
  • the sampling interval At is application-specific and can be specified by the programmer. Large sampling intervals reduce the amount of data to be processed and stored and simplify the learning problem, so that fewer program executions (N) are necessary, but lead to aliasing and undersampling in high-frequency or oscillating processes.
  • the number of program executions N is also application-specific and depends on the complexity and length of the robot movements, the (non-)linearity of the force and moment curves when the robot interacts with the environment, and the stochasticity of the process. If workpiece variances are expected, workpieces from different batches should be used during the exploration phase in order to teach in the workpiece variances.
  • the system models are trained automatically. For each program block of the critical subprograms, a system model is learned based on the previously collected parameter sets and trajectories, which maps the block parameters to the expected positions and orientations of the TCP, the expected forces and moments, and the expected status code. No user interaction is necessary for the training.
  • the training duration depends on the number and complexity of the program modules as well as on the number, length and sampling characteristics of the trajectories in the training data set.
  • a “system modeN” can be defined as a mathematical function / that, given the input parameters x and the system state p, returns the expected trajectory ⁇ . / thus implicitly contains the program logic (the translation of x into control commands for the robot by the robot program), the kinematics and dynamics of the robot, and the physical properties of the environment.
  • the specification of the target function is application-specific and may have to be carried out by an expert in the respective manufacturing domain.
  • a gradient-based optimization method is used for the optimization and the objective function is expressed as a loss function for the equivalent minimization problem.
  • Examples of simple loss functions are the cycle time, the path length in Cartesian or configuration space, or the error probability.
  • Complex loss functions are the distance to one or more reference trajectories, for example from human demonstrations, or the deviation from specified contact forces at the end of a trajectory or during the execution of a program module.
  • An initial target function can be generated automatically by inference using a knowledge base from the semantics of the building blocks of the critical program parts and adapted by the programmer using a graphical user interface.
  • Force-controlled contact travel can be optimized in terms of its dynamic properties by specifying a loss function proportional to the distance of the predicted force along the Z-axis from a specified target force so that the target force is achieved as precisely as possible on average.
  • III. G. Inference phase The program parameters are automatically optimized. For each critical subprogram, the learned system models of the associated program blocks are automatically combined to form an overall model, which maps the parameters of the part program to the combined part trajectory. A gradient-based optimization algorithm iteratively optimizes the program parameters with regard to the given target function. The optimized parameters are automatically transferred to the robot program.
  • Steps A.lll.a to A.lll.c can be skipped since the hyperparameters of the method set there are robust to stochastic changes in the system or the environment.
  • the amount of required training data (cf. A.III.d) is 10-20 times less than in the programming phase, since the existing system models can be post-conditioned to the changed environment using transfer learning methods.
  • Step A.lll.f can also be skipped in many cases if the cycle time and quality specifications have not changed compared to the programming phase. Here, however, there is the possibility of also adapting the target function to the changed conditions in the plant.
  • the integrator determines that components from a different manufacturer are installed in production than those for which the robot cell was fine-tuned during programming. For example, the average orientation of the pins of electronic components has a stochastic offset of up to 2° compared to the programming phase, which means that a large number of search movements fail and the cycle time specifications can no longer be met. By retraining the system model and parameter inference, the distribution of the offset can be implicitly estimated and compensated by the new program parameters.
  • Adaptation to new targets If, for example, cycle time specifications or quality requirements change due to reconfigurations at other points on the production line, the worker can carry out steps A.lll.f and A.lll.g by specifying a corresponding Target function adapt the parameters of the robot program to the new specifications.
  • the existing system models remain valid and can be reused without retraining.
  • Example of contact travel Due to a change of supplier, the pins of the installed electronic components are less resilient than before and bend with the currently planned contact force. By reducing the force specification of the corresponding target function and renewed parameter inference without retraining, a new parameterization can be found that ensures the new, lower contact force.
  • FIG. 5 shows a schematic view of an exemplary system architecture with individual system components for a system for determining optimized program parameters for a robot program according to an exemplary embodiment of the invention.
  • Robot cell 9 with six-axis industrial manipulator It is assumed that forces and moments can be measured at the TCP. An external force-torque sensor may be necessary for this.
  • Block-based graphic programming system 10 for programming and executing robot programs A software system with a graphic user interface is required to create the initial robot program, parameterize it and run it on the robot controller can run on the robot controller.
  • Database 11 for robot programs and trajectories Robot programs are stored serialized in the database 11 in a format that enables the reconstruction of the program structure and parameterization (execution order, type and unique IDs of the program modules, constant and optimizable parameters of the program modules).
  • the database For each execution of the robot program, the database contains a sampled trajectory consisting of the position and orientation of the TCP, forces and moments at the TCP, and the status code of the program module belonging to the data point.
  • the storage format is in such a way that each data point of a trajectory can be clearly assigned to the associated program module and the parameterization of the program module at the time of execution.
  • FIG. 6 shows a schematic representation of the database scheme implemented in an exemplary reference implementation.
  • Learning system 12 for differentiable building block representatives The learning system 12 transforms a serialized representation of the program structure of the critical subprograms into a set of differentiable (parameter-optimizable) motion primitives. Each differentiable movement primitive is a functionally equivalent analogue (“Representative”, “SystemmodeN”) to a block instance from the part program, which maps the parameters of the block instance to a trajectory expected during execution.
  • SystemmodeN Functionally equivalent analogue
  • a block representative is defined as a system model at block level or a model of the execution of the corresponding program block.
  • a block representative for program block B is therefore a mathematical function f B which, given the input parameters x B of the program block and the system state p, outputs the expected trajectory Y B that will result when the program block is executed on the robot.
  • block representatives are mathematical models of the execution of program blocks. These models can be learned from training data and are differentiable, ie they allow the calculation of the derivative of Y B with respect to x B . This allows the optimization of x B with gradient-based optimization methods. Since all block representatives are derivable models of the execution of program blocks, a program composed of block representatives according to FIG.
  • the objective function for the parameter optimization contains sub-goals that are directly results from the execution semantics of the block types.
  • a force-controlled contact run for example, has an implicit contact target in a specified force range.
  • These implicit sub-goals are stored in a knowledge base in the form of an ontology.
  • an initial objective function is created from the given program structure by reasoning over the ontology, which maps these implicit sub-goals. This can be adapted by the user and supplemented with additional, application-specific sub-goals.
  • the use of ontologies or knowledge bases for automatic bootstrapping of target functions represents a significant advantage.
  • An ontology is a structured form of representation for information with logical relations (a knowledge database), which makes it possible to draw logical conclusions from the information contained in the ontology using suitable processing algorithms (reasoning).
  • the developed ontology forms a “database for predefined target functions”, on which target functions can be automatically derived by reasoning from a given semi-symbolic robot program, which due to the fixed semantics of the program modules always must apply, e.g. that a "Contact travel (relative)" block should produce a contact force along the Z axis of the tool coordinate system or that the target point should be reached as precisely as possible with a "Linear movement” block.
  • Differentiable target functions are first precalculated by software by reasoning about the knowledge base of the component-specific sub-goals and can then be processed by the user using an interface if necessary. The resulting internal representation of the combined objective function is then translated into a differentiable computational graph of the loss function for the equivalent minimization problem.
  • Predefined functions that have additional parameters that can be set by the user. Examples are distance functions to default values such as contact forces, tightening torques or Euclidean target poses. The default values can be set by the user via an interface.
  • Inference system 15 for optimal robot parameters The inference system 15 forms a calculation graph that can be optimized end-to-end for each critical subprogram, taking into account the specified target function and the trained component representatives. The inference algorithm uses this graph to calculate the optimal program parameters for the specified target function. This system is new in its design and application in industrial robotics.
  • Graphical user interface for creating, editing and executing robot programs A graphical user interface for the initial Creation and manual processing of program structure and parameterization is planned.
  • the ArtiMinds Robot Programming Suite (RPS) is used as an interface to create and parameterize robot programs in the semi-symbolic ArtiMinds Robot Task Model (ARTM) representation.
  • the user interface also provides infrastructure for executing loaded robot programs on the robot controller.
  • a machine interface for reading, writing and saving of robot program structure and parameterization as well as versioning:
  • the parameter space is randomly sampled and the parameterized robot programs are stored in a database with versioning (cf. system component a.).
  • a machine interface is provided in order to import parameter sets generated by the learning framework into the robot program and to persist the parameterized robot program in a versioned version in a database after execution in order to compare the resulting trajectory with the program structure at the time of training and to associate parameterization.
  • the ArtiMinds RPS control plugin fulfills this function.
  • the example reference implementation includes a console based dialogue system, via which the user can interactively adapt the sub-goals precalculated from the knowledge base and add further sub-goals.
  • the core of a system is a representation of program building blocks, which allows the gradient-based optimization of the parameters with regard to a target function.
  • the inference problem of optimal parameters is divided into a learning phase and an inference phase, with a model of the system (robot and environment during the execution of a building block) being learned in the learning phase and a gradient-based optimization algorithm using the learned system model in the inference phase the input parameters of the block representative have been optimized.
  • Block representatives map the block parameters to an expected trajectory and guarantee that the output trajectory can be differentiated according to the block parameters.
  • This mapping is realized using a recurrent neural network. Since long, finely sampled trajectories in particular contain a lot of redundant information and large sequence lengths make the learning problem significantly more difficult in the case of prediction with neural networks, the neural network becomes analytical trajectory generator connected upstream, which generates a prior trajectory (cf. Fig. 8).
  • the trajectory generator consists of a differentiable implementation of an offline robot simulator.
  • the prior trajectory corresponds to a generic execution of the program block without considering the environment, ie in an artificial space with zero forces and under idealized robot kinematics and dynamics, starting from a given initial state.
  • This strong prior is combined with the building block parameters to form an augmented input sequence for the neural network.
  • the network is trained to predict the residue between the prior and posterior (ie actually measured) trajectory and the probability of success of the block execution (cf. FIG. 8 and the simplified calculation graphs in FIG. 9).
  • the parameter vectors x t of each block representative i depend on the block and are the result of the concatenation of the respective parameters.
  • Pose-valued parameters can be represented as vectors of length 7, where the first 3 entries can represent the position in Cartesian space and the last 4 entries can represent the orientation as a quaternion.
  • the representation as a quaternion has the advantage that they can be interpolated without singularities and the individual components assume smooth curves over time, which significantly simplifies the learning problem.
  • Forces and moments can be represented as vectors of length 6, which designate the forces along the 3 Cartesian spatial directions and the moments about the 3 Cartesian spatial axes.
  • the parameter vectors x t contain both optimizable and constant parameters.
  • the x t of the block representatives can contain fewer or different parameters than the corresponding program blocks, as long as there is a bijection between the parameter vectors and the behavior is the same with the same parameterization.
  • spiral search (relative) The ARTM module accepts four poses for the calculation of the search region, which lie in one plane and describe the four corners of a parallelogram relative to the start pose.
  • this representation is converted into two real numbers that describe the extension of the parallelogram in the x and y directions. This representation is much more compact, but mathematically equivalent. Long x t significantly complicate the learning and inference problem, which is why representations of the parameters that are as compact as possible are advantageous.
  • s t consists of the TCP pose of the last data point of the predicted trajectory, using the convention for poses described above.
  • Characteristics of the method can consist of forces and moments, the joint angle position of the robot or the poses of manipulated objects or objects in the environment detected by external sensors.
  • trajectories are represented as two-dimensional tensors, with the first dimension of variable length representing the time axis. The second dimension is of fixed length.
  • trajectories in the second dimension have 14 entries, with the first 7 entries describing the pose of the TCP in world coordinates according to the above convention and the following 6 entries describing the forces and moments according to the above convention. The last entry is the success probability of a successful movement, with Success ⁇ [0, 1].
  • the space of the trajectories in particular within the scope of the exemplary embodiments, can be denoted by y and a trajectory from this space by ⁇ .
  • the trajectory resulting from the execution of the i-th building block of a robot program can be denoted by ⁇ ⁇ and the n-th vector in the trajectory y i by (y i ) n .
  • Training of the learnable representatives as system models for the sub-process encapsulated in the associated building block - Training algorithm for differentiable building block representatives: By realizing differentiable building block representatives as neural networks, these become trainable. In the exemplary reference implementation according to one embodiment, these are trained on triples (x train , S train , y train ) x train .
  • Y train is a sequence of vectors, each of which contains the absolute position and orientation of the TCP relative to the robot's base coordinate system, forces and moments at the TCP in all Cartesian spatial directions, and the status code, which encodes whether the block was successfully executed .
  • S train is the measured system state at the start of the block's execution.
  • the trajectory generator forms (X train , S train ) on the prior trajectory away.
  • the recurrent neural network maps (X train , ⁇ ⁇ ) to Y res .
  • the prediction of the position, orientation, force and moment components is considered as a common learning problem and a common loss value is calculated using a special loss function. This regression loss is the weighted sum of the mean square error of the position, force and moment components and the angle difference of the orientation component encoded in quaternions.
  • the prediction of the status code is regarded as a binary classification problem and evaluated using binary cross-entropy.
  • Regression and classification loss are combined by weighted addition and the neural network weights are learned using a gradient-based optimization algorithm.
  • the selected representation of trajectories and the regression loss function for trajectories are particularly advantageous.
  • - Implementation For the implementation of the block representatives, a differentiable generator can be implemented in an exemplary reference implementation according to an exemplary embodiment for each supported block type. Since the representatives of different building block types differ structurally only with regard to the length of the parameter vector ⁇ ⁇ , building block representatives can be constructed generically from the associated generator and an untrained neural network. In the reference implementation, the Adam optimization algorithm is used to train the neural networks (see DP Kingma and J.
  • a boolean flag P padding is added in the last dimension of the trajectory tensor, which indicates whether the data point belongs to the padding sequence or not.
  • the training algorithm is extended by another classification problem analogous to the prediction of per f oig .
  • a Python class hierarchy is instantiated, which maps the program structure and whose leaves contain the differentiable building block representatives trained in step 3.
  • the root object (the program abstraction) holds an ordered list of all representatives.
  • the calculation of the overall trajectory is thereby reduced to the evaluation of the calculation graph.
  • the state vectors s t are calculated using only differentiable operations from the predicted partial trajectories of the preceding building blocks (I - L ). In the reference implementation, the calculation corresponds to the extraction of the last pose from Y i-1
  • L error calculates the average probability that the execution of the robot program will fail over all points of the trajectory.
  • the program parameters are optimized using a variant of Neural Network Iterative Inversion (NNII) or gradient descent in the input space (cf. DA Hoskins, JN Hwang, and J. Vagners, “Iterative Inversion of neural networks and its application to adaptive control", IEEE Trans. Neural Netw., Vol. 3, No. 2, pp. 292-301, March 1992, doi: 10.1109/72.125870):
  • NNII Neural Network Iterative Inversion
  • gradient descent in the input space
  • the parameter vectors x t in the calculation graph with an initial parameterization and the start state s 0 is initialized with the current state of the robot cell.
  • the expected overall trajectory is predicted by evaluating the calculation graph and the target function is evaluated.
  • the parameter vectors are incrementally adjusted in the direction of the gradient of the loss function, namely according to the following formula:
  • NNII neural network iterative inversion
  • l denotes the learning rate.
  • the gradients of constantly marked parameters are masked out in each optimization step. After a finite number of iterations (100 ⁇ N ⁇ 1000) the parameters converge in a local minimum.
  • NNII is asymptotically optimal for convex loss functions, ie it converges to a global minimum in any number of iteration steps and with any small learning rate.
  • the global convergence of NNII depends on the initial parameterization due to local minima of the loss function.
  • NNII Neural Network Iterative Inversion
  • the step size (lr or l) is a globally adjustable hyperparameter of the optimization algorithm, the choice of which depends on the application domain, limitations in the computing time for the optimization and the desired convergence properties of the optimization method.
  • Adam converges faster for large values of l, but can oscillate for unfavorable combinations of objective functions.
  • the Adam optimization algorithm can include mechanisms such as weight decay or learning rate Scheduling can be added to dynamically balance convergence and runtime.
  • the PyTorch autograd library is used to calculate the gradients (backpropagate). Apart from the input parameters of the building blocks that can be optimized (optimizable_params), all other parameters (constant building block parameters, but also the weights of the neural networks within the building block representatives) remain constant.
  • the length s of the status vector and the length x of the parameter vector can be set or are block-dependent.
  • the sequence length is set to 500 here.
  • the batch dimension has been omitted for simplicity.
  • the mesh maps inputs (left) to outputs (right).
  • the current state a vector of length p, depending on how the state is encoded as a vector.
  • the length of the status vector depends on the building block; some building blocks may require additional information such as the current gripper opening, etc., which other building blocks do not need.
  • the residual trajectory a tensor of dimension (500, 13).
  • Fig. 8 the This residual is added to the prior trajectory to give the posterior trajectory - P padding : A tensor of dimension (500, 1) that indicates for each time step of the trajectory whether it belongs to the padding or not (contains values between 0 and 1).
  • - Success A tensor of dimension (500, 1) which, for each time step of the trajectory, specifies the success probability of the building block at this point in time (contains values between 0 and 1).
  • the function is as follows: - First, the state and the input vector are converted into tensors of the dimensions (500, p) and (500, x) by repetition.
  • the GRUs are "residual" (this has nothing to do with the residual trajectory , ie the outputs of a GRU are not only inputs for the following GRU, but also for the one after that. This is indicated in FIG. 10 by the thin arrows and the dashed tensors. - The output of the last GRU is transformed into the residual trajectory, P padding and PerfoIg by a last fully connected layer. Each layer is followed by a subsequent activation function, which is not shown in FIG. 10 for the sake of simplicity.
  • SELU Scaled Exponential Linear Units
  • the training becomes particularly efficient when the network is trained on batches of training data in parallel on a graphics card (GPU).
  • the batch dimension has been omitted from Figure 10 for simplicity.
  • batches of size 64 can be used.

Landscapes

  • Engineering & Computer Science (AREA)
  • Robotics (AREA)
  • Mechanical Engineering (AREA)
  • Automation & Control Theory (AREA)
  • Evolutionary Computation (AREA)
  • Artificial Intelligence (AREA)
  • Physics & Mathematics (AREA)
  • Fuzzy Systems (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • Manipulator (AREA)
  • Numerical Control (AREA)
  • Feedback Control In General (AREA)

Abstract

Ein Verfahren zur Bestimmung von optimierten Programmparametern für ein Roboterprogramm, wobei das Roboterprogramm zur Steuerung eines Roboters mit einem Manipulator, vorzugsweise in einer Roboterzelle, dient, umfassend die Schritte: Erzeugen des Roboterprogramms mittels eines bausteinbasierten grafischen Programmiersystems basierend auf Benutzereingaben, wobei das Roboterprogramm aus Programmbausteinen, die über Programmparameter parametrierbar sind, gebildet wird, und wobei initiale Programmparameter für die Programmbausteine des Roboterprogramms erzeugt werden; Bereitstellen einer Schnittstelle zum Auswählen eines oder mehrerer kritischer Programmbausteine, wobei optimierbare Programmparameter für die kritischen Programmbausteine festlegbar sind; Durchführen einer Explorationsphase zur Exploration eines Parameterraums in Bezug auf die optimierbaren Programmparameter, wobei das Roboterprogramm mehrfach ausgeführt wird, wobei eine Abtastung des Parameterraums für die kritischen Programmbausteine durchgeführt wird und Trajektorien des Roboters aufgezeichnet werden, so dass für die kritischen Programmbausteine Trainingsdaten vorliegen; Durchführen einer Lernphase zum Erzeugen von Bausteinrepräsentanten für die kritischen Programmbausteine des Roboterprogramms basierend auf den in der Explorationsphase gesammelten Trainingsdaten, wobei ein Bausteinrepräsentant ein Systemmodell darstellt, das in Form einer differenzierbaren Funktion einen vorgegebenen Zustand des Roboters und vorgegebene Programmparameter auf eine prädizierte Trajektorie abbilden; Durchführen einer Inferenzphase zur Bestimmung von optimierten Programmparametern für die kritischen Programmbausteine des Roboterprogramms, wobei mittels eines gradientenbasierten Optimierungsverfahrens unter Einsatz der Bausteinrepräsentanten optimierbare Programmparameter der Bausteinrepräsentanten bezüglich einer vorgegebenen Zielfunktion iterativ optimiert werden. Ferner ist ein entsprechendes System offenbart.

Description

„Verfahren und System zur Bestimmung von optimierten Programmpa- rametern für ein Roboterprogramm“
Die Erfindung betrifft ein Verfahren und System zur Bestimmung von optimierten Pro- grammparametern für ein Roboterprogramm, wobei das Roboterprogramm zur Steu- erung eines Roboters mit einem Manipulator, vorzugsweise in einer Roboterzelle, dient.
Verfahren und Systeme zur Bestimmung von Programmparametern für ein Roboter- programm sind seit Jahren aus der Praxis bekannt. Dabei beziehen sich diese auf die Programmierung eines Roboters, wobei geeignete Programmparameter meist manu- ell für das entsprechende Roboterprogramm zu wählen sind.
In der fertigenden Industrie werden Industrieroboter insbesondere dann für die Lö- sung komplexer Manipulations- und Montageaufgaben sowie für die Oberflächenbe- handlung eingesetzt, wenn die zu bearbeitenden Werkstücke oder die zu erledigen- den Anwendungsaufgaben ein Maß an Variabilität aufweisen. Die Fähigkeit industri- eller Roboterarme, nahezu beliebige Werkzeug- oder Werkstückpositionen und -Ori- entierungen innerhalb ihres Arbeitsraums anzufahren, ermöglicht in Kombination mit geeigneten Endeffektoren die Lösung unterschiedlicher Anwendungsaufgaben oder die Verarbeitung unterschiedlicher Werkstückvarianten innerhalb einer Roboterzelle.
Fertigungszellen mit Industrierobotern werden traditionell textuell programmiert, wo- bei für die initiale Parametrierung Posen oder Teilbewegungen per Teach-In-Verfah- ren über sogenannte Teach-Pendants eingelernt werden. Zahlreiche herstellerspezi- fische und herstellerübergreifende kommerzielle Produkte erleichtern die Offline-Pro- grammierung von Roboterzellen durch die automatische Erzeugung von Robotercode sowie halbautomatische Bahngenerierung anhand von CAD-Modellen der Roboter- zelle und der zu bearbeitenden Werkstücke („CAD to Path“). Bausteinbasierte Pro- grammiersystem bzw. Programmiersoftware wie die ArtiMinds Robot Programming Suite (RPS), RoboDK oder drag&bot vereinfachen die Roboterprogrammierung durch die Kapselung atomarer Bewegungsprimitive in abstrakte Programmbausteine, die zu komplexen Manipulationssequenzen kombiniert werden können. Symbolische, parametrierbare Programmrepräsentationen sind eine etablierte Praxis in der Service- und Industrierobotik. Taskmodelle bestehen in der Regel aus atoma- ren, parametrierbaren Aktionsprimitiven, welche durch Kontrollfluss- und Logikprimi- tive zu komplexen Aktionssequenzen kombiniert und in Sequenzen konkreter Robo- terbewegungen übersetzt werden können. Generalisierte Manipulationsstategien und deren Implementierung, wie zum Beispiel das ArtiMinds Task Model, repräsentieren Aktionsprimitive als Gruppen ggf. gelernter Constraints (Bedingungen) im Gelenkwin- kel- oder kartesischen Raum, aus welchen Bewegungen erzeugt werden, die diese Constraints erfüllen. Hierzu sei beispielsweise auf die DE 10 2015 204 641 A1 ver- wiesen.
Andere Ansätze erzeugen abstrakte Task-Pläne aus ontologiebasierten Wissensda- tenbanken oder verwenden explizite Domain-Specific Languages (DSLs), um das zu lösende Problem zu spezifizieren und Aktionen des Roboters abzuleiten.
In der Industrie ist die Optimierung von Programmparametern ein überwiegend ma- nueller Prozess, der Expertenwissen voraussetzt. Für die visuelle und quantitative Unterstützung dieses Prozesses existieren diverse kommerzielle Produkte, welche nach Aggregation und statistischer Auswertung der Daten von Robotern sowie exter- ner Sensorik und Aktorik Prozesskenngrößen berechnet und Prozessdaten visuell aufbereitet. Beispiele sind die kommerzielle Softwarelösung ArtiMinds Learning & Analytics for Robots (LAR), KUKA Connect, Siemens MindSphere, Bosch Nexeed oder IXON. Mit dem Feature Teach-Point Optimization (TPO) ermöglicht beispiels- weise ArtiMinds LAR die automatische Anpassung einzelner Roboterprogrammpara- meter anhand von Statistiken über vergangene Programmausführungen. Die meisten Roboter in komplexen Fertigungsanlagen werden im externen Automatikmodus be- trieben und zur Laufzeit von speicherprogrammierbaren Steuerungen automatisch parametriert, wobei die Parametersätze in der Regel pro Charge fest vorgegeben sind. Einige Plattformen wie MindSphere oder Nexeed ermöglichen die Optimierung und Anpassung bestimmter Parameter der Prozesssteuerung, um Kenngrößen wie Durchsatz oderTaktzeit zu optimieren, operieren jedoch auf der Makroebene, so dass beispielsweise eine Feinabstimmung von Programmteilen eines Roboterprogramms nicht möglich ist. Da das Verhalten eines Roboters in Software spezifiziert ist, verlagert sich der Ent- wicklungs- und Wartungsaufwand von Roboterzellen weg von der Hardware in die Software. Eine robuste Lösung komplexer Manipulationsaufgaben mit Industrierobo- tern hängt hierbei stark von aufgabenspezifischen Programmparametern wie Ge- schwindigkeiten, Beschleunigungen, Kraftvorgaben oder Zielpunkten ab, die genau auf die zu lösende Aufgabe, die Geometrie und physikalischen Eigenschaften der Roboterzelle sowie die zu bearbeitenden Werkstücke abgestimmt werden müssen. Gerade bei der Inbetriebnahme neuer Roboterzellen ist die Feinabstimmung der Pro- grammparameter sehr zeitaufwendig, erfordert hochspezialisiertes Expertenwissen und verzögert den produktiven Betrieb der Roboterzelle.
Der vorliegenden Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren und ein System zur Bestimmung von optimierten Programmparametern für ein Roboterpro- gramm der eingangs genannten Art derart auszugestalten und weiterzubilden, dass eine Findung von optimierten Programmparametern für das Roboterprogramm ver- einfacht bzw. verbessert wird.
Erfindungsgemäß wird die voranstehende Aufgabe durch die Merkmale des Anspru- ches 1 gelöst. Danach ist ein Verfahren zur Bestimmung von optimierten Programm- parametern für ein Roboterprogramm angegeben, wobei das Roboterprogramm zur Steuerung eines Roboters mit einem Manipulator, vorzugsweise in einer Roboter- zelle, dient, wobei das Verfahren die folgenden Schritte umfasst:
Erzeugen des Roboterprogramms mittels eines bausteinbasierten grafischen Programmiersystems basierend auf Benutzereingaben, wobei das Roboterprogramm aus Programmbausteinen, die über Programmparameter parametrierbar sind, gebil- det wird, und wobei initiale Programmparameter für die Programmbausteine des Ro- boterprogramms erzeugt werden;
Bereitstellen einer Schnittstelle zum Auswählen eines oder mehrerer kritischer Programmbausteine, wobei optimierbare Programmparameter für die kritischen Pro- grammbausteine festlegbar sind;
Durchführen einer Explorationsphase zur Exploration eines Parameterraums in Bezug auf die optimierbaren Programmparameter, wobei das Roboterprogramm mehrfach ausgeführt wird, wobei eine Abtastung des Parameterraums für die kriti- sehen Programmbausteine durchgeführt wird und Trajektorien des Roboters aufge- zeichnet werden, so dass für die kritischen Programmbausteine Trainingsdaten vor- liegen;
Durchführen einer Lernphase zum Erzeugen von Bausteinrepräsentanten für die kritischen Programmbausteine des Roboterprogramms basierend auf den in der Explorationsphase gesammelten Trainingsdaten, wobei ein Bausteinrepräsentant ein Systemmodell darstellt, das in Form einer differenzierbaren Funktion einen vorgege- benen Zustand des Roboters und vorgegebene Programmparameter auf eine prädi- zierte Trajektorie abbilden;
Durchführen einer Inferenzphase zur Bestimmung von optimierten Programm- parametern für die kritischen Programmbausteine des Roboterprogramms, wobei mit- tels eines gradientenbasierten Optimierungsverfahrens unter Einsatz der Bausteinre- präsentanten optimierbare Programmparameter der Bausteinrepräsentanten bezüg- lich einer vorgegebenen Zielfunktion iterativ optimiert werden.
Die voranstehende Aufgabe ist des Weiteren durch die Merkmale des Anspruchs 17 gelöst. Danach ist ein System zur Bestimmung von optimierten Programmparametern für ein Roboterprogramm angegeben, wobei das Roboterprogramm zur Steuerung eines Roboters mit einem Manipulator, vorzugsweise in einer Roboterzelle, dient. Die- ses System umfasst: ein bausteinbasiertes grafisches Programmiersystem zum Erzeugen eines Ro- boterprogramms basierend auf Benutzereingaben, wobei das Roboterprogramm aus Programmbausteinen, die über Programmparameter parametrierbar sind, gebildet wird, und wobei initiale Programmparameter für die Programmbausteine des Robo- terprogramms erzeugbar sind; eine Schnittstelle zum Auswählen eines oder mehrerer kritischer Programm- bausteine, wobei optimierbare Programmparameter für die kritischen Programmbau- steine festlegbar sind; ein Explorationsmodul zur Exploration eines Parameterraums in Bezug auf die optimierbaren Programmparameter, wobei das Roboterprogramm mehrfach ausge- führt wird, wobei eine Abtastung des Parameterraums für die kritischen Programm- bausteine durchgeführt wird und Trajektorien des Roboters aufgezeichnet werden, so dass für die kritischen Programmbausteine Trainingsdaten vorliegen; ein Lernmodul zum Erzeugen von Bausteinrepräsentanten für die kritischen Programmbausteine des Roboterprogramms basierend auf den in der Explorations- phase gesammelten Trainingsdaten, wobei ein Bausteinrepräsentant ein Systemmo- dell darstellt, das in Form einer differenzierbaren Funktion einen vorgegebenen Zu- stand des Roboters und vorgegebene Programmparameter auf eine prädizierte Trajektorie abbilden; ein Inferenzmodul zur Bestimmung von optimierten Programmparametern für die kritischen Programmbausteine des Roboterprogramms, wobei mittels einem gra- dientenbasierten Optimierungsverfahren unter Einsatz der Bausteinrepräsentanten optimierbare Programmparameter der Bausteinrepräsentanten bezüglich einer vor- gegebenen Zielfunktion iterativ optimiert werden.
In erfindungsgemäßer Weise ist zunächst erkannt worden, dass es von ganz erheb- lichem Vorteil ist, wenn für ein Roboterprogramm optimierte bzw. für die jeweilige Anwendung möglichst optimale Programmparameter weitestgehend automatisiert gefunden werden können. In weiter erfindungsgemäßer Weise ist erkannt worden, dass eine Feinabstimmung bzw. Feineinstellung (Fine-Tuning) von kritischen Pro- grammteilen eines Roboterprogramms und deren Optimierung hinsichtlich anwen- dungsspezifischer Zielfunktionen erhebliche Effizienzsteigerungen hinsichtlich der Programmier-, Inbetriebnahme- und/oder Wartungsphase eines Roboters verspricht. Zur Festlegung einer Programmstruktur wird zunächst mittels eines bausteinbasier- ten grafischen Programmiersystems basierend auf Benutzereingaben ein Roboter- programm erzeugt. Dabei wird das Roboterprogramm aus Programmbausteinen ge- bildet, wobei die Programmbausteine über Programmparameter parametrierbar sind. Das Roboterprogramm stellt daher ein semi-symbolisches Roboterprogramm dar. Des Weiteren werden initiale und damit vorläufige Programmparameter für die Pro- grammbausteine des Roboterprogramms erzeugt bzw. festgelegt.
Erfindungsgemäß können dann mit einer bereitgestellten Schnittstelle ein oder meh- rere kritische Programmbausteine ausgewählt werden, wobei optimierbare Pro- grammparameter für die kritischen Programmbausteine festlegbar sind. Im Rahmen einer Explorationsphase erfolgt eine automatische und stochastische Exploration ei- nes Parameterraums in Bezug auf die optimierbaren Programmparameter. Dazu wird das Roboterprogramm mehrfach bzw. wiederholt ausgeführt, wobei eine automati- sehe Abtastung des Parameterraums für die kritischen Programmbausteine durchge- führt wird und resultierende Trajektorien des Roboters aufgezeichnet werden. Somit können zu jeder Ausführung des Roboterprogramms für die kritischen Programmbau- steine Trainingsdaten gesammelt werden.
Im Rahmen einer anschließenden Lernphase werden Bausteinrepräsentanten für die kritischen Programmbausteine des Roboterprogramms erzeugt, wobei dies unter Verwendung der in der Explorationsphase gesammelten Trainingsdaten erfolgt. Ein Bausteinrepräsentant ist hierbei ein Systemmodell, das in Form einer differenzierba- ren Funktion einen vorgegebenen in der Explorationsphase gemessenen bzw. ermit- telten Zustand des Roboters und vorgegebene Programmparameter auf eine prädi- zierte - d.h. eine zu erwartende - Trajektorie abbildet.
Schließlich werden in einer Inferenzphase optimierte Programmparametern für die kritischen Programmbausteine des Roboterprogramms bestimmt. Dazu werden mit- tels eines gradientenbasierten Optimierungsverfahrens unter Einsatz der zuvor er- zeugten Bausteinrepräsentanten optimierbare Programmparameter der Bausteinre- präsentanten bezüglich einer vorgegebenen Zielfunktion iterativ optimiert. Dadurch wird beispielweise ein optimaler Parametervektor für jeden kritischen Baustein ge- wonnen. Die optimierten Programmparameter können automatisch in das Roboter- programm übertragen werden. Somit kann ein Roboterprogramm mit hinsichtlich ei- ner vorgegebenen Zielfunktion optimalen Programmparametern erreicht werden.
Folglich ist mit dem erfindungsgemäßen Verfahren zur Bestimmung von optimierten Programmparametern für ein Roboterprogramm und mit dem erfindungsgemäßen System eine vereinfachte und verbesserte Findung von optimierten Programmpara- metern ermöglicht.
Unter einem „bausteinbasierten grafischen Programmiersystem“ kann - insbeson- dere im Rahmen der Ansprüche und vorzugsweise im Rahmen der Beschreibung - ein Programmiersystem bzw. eine Programmiersoftware verstanden werden, das bzw. die eine Kapselung atomarer Bewegungsprimitive in abstrakte Programmbau- steine erlaubt, wobei die Programmbausteine zu komplexen Manipulationssequen- zen kombiniert werden können. Lediglich beispielhaft sei die ArtiMinds Robot Pro- gramming Suite (RPS), RoboDK oder drag&bot als mögliche bausteinbasierte Pro- grammiersysteme genannt.
Unter einem „semi-symbolisches Roboterprogramm“ kann - insbesondere im Rah- men der Ansprüche und vorzugsweise im Rahmen der Beschreibung - ein Roboter- programm verstanden werden, das eine symbolische Struktur (zusammengesetzt aus einzelnen Programmbausteinen) aufweist, dessen Komponenten (die Programmbau- steine) jedoch in ihrem Verhalten variabel sind, da das genaue Verhalten der Bau- steine noch von der Parametrierung abhängt). Diskrete Programmbausteine, die aber jeweils parametrierbar sind, haben beide Eigenschaften und können daher als semi- symbolisch angesehen werden. Ein bausteinbasiertes grafisches Programmiersys- tem kann ein semi-symbolisches Roboterprogramm erzeugen.
An dieser Stelle sei angemerkt, dass unter einem „Programmbaustein“ - insbeson- dere im Rahmen der Ansprüche und vorzugsweise im Rahmen der Beschreibung - die kleinste vom Nutzer konfigurierbare Einheit eines symbolischen oder semi-sym- bolischen Roboterprogramms verstanden werden kann. Der Programmbaustein re- präsentiert eine vordefinierte Aktion des Roboters. Programmbausteine können se- quentiell zu komplexen Roboterprogrammen kombiniert werden. Programmbausteine sind parametrierbar, d.h. sie akzeptieren einen Vektor von Parametern, deren Werte durch den Roboterprogrammierer bei der Erstellung des Roboterprogramms vorge- geben werden können. Jeder Programmbaustein hat genau einen Typ, welcher die Aktion, die der Programmbaustein repräsentiert, bestimmt. Beispiele für Programm- bausteine sind „Greifen“, „Punkt-zu-Punkt-Bewegung“, „Kontaktfahrt (Relativ)“, „Kreisbogenfahrt“, „Spiralsuche (Relativ)“, „Momentengeregeltes Fügen“, „Kraftgere- geltes Drücken“, „Palettieren“ etc.
Unter einem „kritischen Programmbaustein“ kann - insbesondere im Rahmen der An- sprüche und vorzugsweise im Rahmen der Beschreibung - ein Programmbaustein verstanden werden, für welchen optimierte Parameter zu bestimmen sind.
Unter einem „Bausteinrepräsentanten“ kann - insbesondere im Rahmen der Ansprü- che und vorzugsweise im Rahmen der Beschreibung - ein Systemmodell für einen Programmbaustein verstanden werden, welches das Verhalten des Programmbau- steins während dessen Ausführung modelliert. Zum Beispiel kann ein Bausteinreprä- sentant im Sinne der Definition eines Systemmodells einen Vektor von Eingabepara- metern und den zum Ausführungszeitpunkt vorliegenden Systemzustand auf die bei der Ausführung zu erwartende Trajektorie abbilden, wobei das System im Sinne der Definition eines Systemmodells den Roboterarm sowie ggf. die Umgebung des Ro- boters und ggf. die bei der Ausführung des Programmbausteins manipulierten Ob- jekte beinhalten kann.
Unter einem „SystemmodeN“ kann - insbesondere im Rahmen der Ansprüche und vorzugsweise im Rahmen der Beschreibung - ein mathematisches Modell verstan- den werden, welches das Verhalten eines Systems vereinfachend approximiert. Zum Beispiel kann ein „SystemmodeN“ definiert sein als eine mathematische Funktion /, die gegeben den Eingabeparametern x und dem Systemzustand p die erwartete Trajektorie Ϋ ausgibt. / beinhaltet somit implizit die Programmlogik (die Übersetzung von x in Steuerbefehle für den Roboter durch das Roboterprogramm), die Kinematik und Dynamik des Roboters, und die physikalischen Eigenschaften der Umgebung.
Insbesondere im Rahmen der Ansprüche und vorzugsweise im Rahmen der Be- schreibung kann unter einer „Trajektorie“ eine mit festem Abtastintervall abgetastete Sequenz von Vektoren verstanden werden, welche Informationen über den Zustand des Roboters und optional auch über dessen Umgebung enthalten kann. Lediglich als Beispiel im Rahmen einer vorteilhaften Ausgestaltung können Trajektorien zu je- dem Zeitschrift eine oder mehrere der folgenden Informationen enthalten:
- Die Position und Orientierung des Endeffektors (Tool-Center-Point (TCP)/Werkzeugkoordinatensystem)
- Die am Endeffektor anliegenden Kräfte und Momente
- Einen Statuscode ( perfoig ) zwischen 0 und 1 , welcher angibt, ob während der Bewegungsausführung ein Fehler auftrat, z.B. ob die Kraftvorgabe bei einer kraftgeregelten Bewegung verletzt wurde.
In einer erweiterten - lediglich beispielhaften - Ausgestaltung wäre es denkbar und vorteilhaft, Trajektorien um eine oder mehrere der folgenden Informationen zu erwei- tern: - Die aktuelle Gelenkwinkelkonfiguration des Roboters. Dies würde das Lernen von Systemmodellen für Bausteine deutlich erleichtern, deren Ausführungsse- mantik im Gelenkwinkelraum definiert ist (z.B. „Punkt-zu-Punkt-Bewegung“: Li- nearbewegung im Gelenkwinkelraum).
- Die Positionen und Orientierungen von Objekten in der Umgebung, die von dem Roboter manipuliert werden. Dies würde es ermöglichen, Zielfunktionen für die Parameteroptimierung über Relationen zwischen Objekten zu formulie- ren, zum Beispiel „Objekt A soll sich nach der Bewegung zwischen Objekt B und Objekt C befinden“ oder „Objekt A soll während der Programmausführung Kontakt zu Objekt B halten“.
In vorteilhafter Weise können für die optimierbaren Programmparameter der kriti- schen Programmbausteine Parameterdomänen festgelegt werden, wobei die opti- mierbaren Programmparameter über die Parameterdomänen optimiert werden. Eine Parameterdomäne stellt für den optimierbaren Programmparameter einen zulässigen Wertebereich dar. Zweckmäßigerweise ist für jeden optimierbaren Programmpara- meter ein zulässiger Wertebereich bzw. eine Parameterdomäne vorgesehen.
In weiter vorteilhafter Weise können die Parameterdomänen für die optimierbaren Programmparameter der kritischen Programmbauseine vorgegeben und/oder vor- gebbar bzw. einstellbar sind. Demnach kann eine Domäne auch voreingestellt sein. Das heißt die Parameterdomäne für einen Programmparameter könnte bereits durch das zugrundeliegende System vorgegeben sein. Des Weiteren ist denkbar, dass ein Roboterprogrammierer/Nutzer für die zu optimierenden Programmparameter der kri- tischen Programmbausteine eine Parameterdomäne auswählt, über welche optimiert werden soll. Diese Parameterdomäne ist anwendungsspezifisch und zweckmäßiger- weise ausreichend schmal zu wählen, so dass Sicherheitsanforderungen an den Fer- tigungsprozess sowie Mindestanforderungen an Qualität und Zykluszeit erfüllt wer- den.
Im Hinblick auf eine Gewinnung von geeigneten Trainingsdaten können in der Explo- rationsphase zur Abtastung des Parameterraums die optimierbaren Programmpara- meter aus ihrer jeweiligen Parameterdomäne gesampelt werden. Das heißt, die opti- mierbaren Programmparameter werden zufällig als Stichprobe aus der Parameterdo- mäne ausgewählt. Dabei ist denkbar, dass die optimierbaren Programmparameter gleichverteilt gesampelt werden, also ein gleichverteiltes Sampling durchgeführt wird. Dies liefert den Vorteil, dass sich etwaige Abtastungsfehler breit über den Abtastungs- raum verteilen. Ein gleichverteiltes Sampling liefert ausreichend viel Zufall, um syste- matische Unterabtastungen zu vermeiden, und sorgt dabei für eine gleichmäßige Ab- deckung des Parameterraums. Des Weiteren ist denkbar, dass die optimierbaren Pro- grammparameter adaptiv gesampelt werden. Es kann also ein adaptives Sampling durchgeführt werden und sampelt zweckmäßigerweise dort bzw. in den Bereichen, wo noch Informationen benötigt werden.
In vorteilhafter Weise kann das Roboterprogramm, vorzugweise in einer Datenbank, in einem Format derart serialisiert abgespeichert werden, dass das Format eine Re- konstruktion und Parametrierung des Roboterprogramms bzw. dessen Programm- bausteinen ermöglicht. In weiter vorteilhafter Weise kann das Format eine sequenti- elle Ausführungsreihenfolge der Programmbausteine, Typen der Programmbau- steine, IDs der Programmbausteine, konstante Programmparameter und/oder opti- mierbare Programmparameter umfassen. Somit lässt sich durch das Format und die gespeicherten Daten eine besonders effiziente Flandhabung und Implementierung er- reichen. Weitere Vorteile dieser Merkmale umfassen die Möglichkeit, anhand der ge- speicherten Programmstruktur, Bausteintypen und -parameter die Gesamtsystem- modelle, bestehend aus Sequenzen der Bausteinrepräsentanten für die in der Pro- grammstruktur enthaltenen Bausteine, vollautomatisch zu erzeugen. Ein Weiterer Vorteil ist die Möglichkeit, zu einem beliebigen späteren Zeitpunkt Daten früherer Ex- plorationen (ggf. für andere Roboterprogramme) in Teilen für das Training neuer Bau- steinrepräsentanten (z.B. für die Ausführung in geänderten Umgebungen, etc.) für Bausteine desselben Bausteintypen wiederzuverwenden, da das spezifizierte Format das nachträgliche Auslesen von Bausteintypen und -parametern ermöglicht.
In vorteilhafter Weise kann für eine bzw. für jede in der Explorationsphase ausge- führte Ausführung des Roboterprogramms eine resultierende, abgetastete Trajektorie derart gespeichert werden, dass jedem Datenpunkt der Trajektorie ein dazugehöriger Programmbaustein und eine Parametrierung des dazugehörigen Programmbausteins zum Zeitpunkt der jeweiligen Ausführung eindeutig zuordenbar ist. Dies ermöglicht besonders effiziente Handhabung und Implementierung der mit der Trajektorie ge- speicherten Daten. Ein Vorteil dieses Formats ist die Möglichkeit, die gespeicherten Daten nachträglich zu beliebigen späteren Zeitpunkten für das Training neuer Bau- steinrepräsentanten desselben Typs erneut zu verwenden, da die Teiltrajektorien für Programmbausteine spezifischer Typen direkt zugeordnet und aus der Gesamttrajek- torie extrahiert werden können.
Hinsichtlich der Sammlung von Trainingsdaten in der Explorationsphase kann das Roboterprogramm automatisiert ausgeführt werden, wobei mindestens 100 Ausfüh- rungen, vorzugweise mindestens 1000 Ausführungen, des Roboterprogramms zur Gewinnung der Trainingsdaten durchgeführt werden. Die automatisierte Ausführung des Roboterprogramms hat den Vorteil, dass während der Explorationsphase keine menschlichen Ressourcen gebunden werden und ermöglicht die zeit- und ressour- ceneffiziente Sammlung realer Trainingsdaten. Die Anzahl der Ausführungen des Ro- boterprogramms während der Explorationsphase wirkt sich vorteilhaft auf die Qualität der in der Inferenzphase optimierten Programmparameter aus, da eine höhere An- zahl Trainingsdaten eine feinere Abtastung des Parameterraums sowie des System- verhaltens bedeutet, wodurch die den Bausteinrepräsentanten zugrundeliegenden neuronalen Netze lernen können, das Systemverhalten bei unterschiedlichen Para- metern robuster und präziser zu approximieren. Da die Bausteinrepräsentanten die Grundlage für das System zur Optimierung der Programmparameter bilden, sind bei größeren Mengen von Trainingsdaten grundsätzlich optimierte Parametersätze zu er- warten, die der global optimalen Parametrierung näher kommen.
In vorteilhafter Weise können die in der Explorationsphase gesammelten Trainings- daten zu jeder Ausführung des Roboterprogramms eine Parametrierung, insbeson- dere konstante und/oder optimierbare Programmparameter, der kritischen Pro- grammbausteine und eine jeweils resultierende, abgetastete Trajektorie der kriti- schen Programmbausteine umfassen. Somit lassen sich in der Lernphase die Bau- steinrepräsentanten erzeugen. Dabei können die in der Explorationsphase zufällig gesampelten, d.h. zufällig generierten, optimierbaren Programmparameter als Teil der Trainingsdaten gespeichert und mit der Ausführung des Roboterprogramms as- soziiert werden. Die gemeinsame Speicherung von Programmparametern und Trajektorien vereinfacht die Implementierung deutlich, da lediglich eine Datenbank bzw. ein Speicherformat angebunden werden muss. In vorteilhafter Weise können die in der Explorationsphase gesammelten Trainings- daten zu jedem ausgeführten Programmbaustein zusätzlich eine ID (das heißt einen Identifikator bzw. eine Kennung) und/oder ein Statuscode umfassen. Die ID kann für die Zuordnung eines Bausteins und einem Parameter zu dem Baustein sowie einer Trajektorie zu dem Baustein verwendet werden. Der Statuscode kann verwendet wer- den, um Erfolg/Fehler der Ausführung zu speichern und kann daher ein wichtiger Teil der Programmbausteinsemantik sein, den die Bausteinrepräsentanten lernen kön- nen. Somit kann man zum Beispiel als Zielfunktion für die Optimierung die Fehlerrate minimieren. Folglich wird das Spektrum an möglichen, einsetzbaren Zielfunktionen erweitert.
Hinsichtlich der effizienten Erzeugung von Bausteinrepräsentanten können in der Lernphase für die kritischen Programmbausteine zunächst lernbare Bausteinreprä- sentanten erzeugt werden, wobei die lernbaren Bausteinrepräsentanten mit den Trai- ningsdaten der Explorationsphase trainiert werden, um dann als gelernte Bausteinre- präsentanten Systemmodelle für in den dazugehörigen kritischen Programmbaustei- nen gekapselten Teilprozesse darzustellen. Dies ermöglicht die einfache software- technische Umsetzung von Bausteinrepräsentanten als objektorientierte Klassen (für jeden Typ von Programmbaustein gibt es eine (Software-) Klasse, welche die Imple- mentierung des Trajektoriengenerators für diesen Bausteintyp, die Architektur des neuronalen Netzes und die für das Training notwendige Logik beinhaltet). Diese Klas- sen müssen nur einmal (z.B. als Teil eines Softwareprodukts für die grafische Robo- terprogrammierung) entwickelt werden und können dann wiederholt zu konkreten Bausteinrepräsentanten instantiiert werden, deren neuronales Netz dann trainiert wird.
In vorteilhafter Weise können die Bausteinrepräsentanten ein rekurrentes neuronales Netz umfassen. Diese liefert eine universale Anwendbarkeit. Da durch das rekurrente neuronale Netz ein tiefes neuronales Netz als Systemmodell eingesetzt wird, trifft das beschriebene Vorgehen bei der Modellbildung keine Annahmen über die Natur (z.B. parametrische Verteilung, Normalverteilung, Linearität) der Ein- und Ausgabedaten und ist demnach in allen Fertigungsdomänen sowie prinzipiell für alle Bausteintypen einsetzbar. Da bis auf eine Differenzierbarkeit keine weiteren Anforderungen an die Zielfunktion gestellt werden, sind beliebige Zielfunktionen denkbar. Das Verfahren ist somit in beliebigen Anwendungsdomänen wie Montage, Oberflächenbearbeitung o- der Handling einsetzbar und ermöglicht die Optimierung von Roboterprogrammen hinsichtlich beliebiger Prozesskennzahlen oder Qualitätskriterien.
Im Hinblick auf eine effiziente Erzeugung von Bausteinrepräsentanten kann dem re- kurrenten neuronalen Netz ein analytischer Trajektoriengenerator, der zweckmäßi- gerweise differenzierbar implementiert ist, vorgeschaltet werden. Der analytische Trajektoriengenerator ist dabei dazu ausgebildet ist, eine priore Trajektorie zu erzeu- gen. Da insbesondere lange, fein abgetastete Trajektorien viel redundante Informa- tion enthalten und bei der Prädiktion mit neuronalen Netzen große Sequenzlängen das Lernproblem deutlich erschweren können, wird dem entgegengewirkt, indem dem neuronalen Netz ein analytischer Trajektoriengenerator vorgeschaltet wird. Die- ser erzeugt eine priore Trajektorie. Zum Beispiel kann der Trajektoriengenerator aus einer differenzierbaren Implementierung eines Offline-Robotersimulators bestehen. So können z.B. Softwarebibliotheken zur Bewegungsplanung mit Robotern wie Orocos KDL (https://www.orocos.org/kdl) oder Movelt (https://moveit.ros.org/) ange- passt und um Differenzierbarkeit, d.h. Ableitbarkeit der Ausgabe (der prioren Trajek- torie) nach den Eingabeparametern, ergänzt werden. Konkret können die dort imple- mentierten Algorithmen für die Bewegungsplanung in differenzierbare Berechnungs- graphen überführt werden. Diese Überführung kann in einer beispielhaften Implemen- tierung gemäß einem Ausführungsbeispiel durch Reimplementierung der Planungs- algorithmen mit Hilfe der Softwarebibliothek PyTorch (https://pytorch.org/), welche die Differenzierbarkeit garantiert. Die priore Trajektorie kann einer generischen Ausfüh- rung des Programmbausteins ohne Betrachtung der Umgebung entsprechen, d.h. in einem künstlichen Raum mit Nullkräften und unter idealisierter Roboterkinematik und -dynamik, ausgehend von einem gegebenen Startzustand. Diese starke Priore (strong prior) kann mit den Bausteinparametern zu einer augmentierten Eingabese- quenz für das neuronale Netz kombiniert werden. Das Netz kann dann darauf trainiert werden, das Residuum zwischen priorer und posteriorer (d.h. real gemessener) Trajektorie sowie die Erfolgswahrscheinlichkeit der Bausteinausführung zu prädizie- ren. Die Addition von Residuum und Priore kann die ausgegebene erwartete posteri- ore Trajektorie für diesen Progammbaustein und die gegebenen Bausteinparameter ergeben. Eine Vereinfachung des Lernproblems beim Training neuronaler Netze durch die Einführung starker Priore ist etablierte Praxis. Durch den Einsatz starker Priore kann der Bedarf an Trainingsdaten um eine Größenordnung deutlich reduziert werden. Dieser Effekt ist bei langen Trajektorien oder Trajektorien mit starkem Deter- minismus besonders markant. Der Einsatz eines differenzierbar implementierten ana- lytischen Generators als starke Priore ist somit besonders vorteilhaft.
In vorteilhafter Weise kann die Zielfunktion derart festgelegt werden, dass die Ziel- funktion eine Trajektorie auf eine rationale Zahl abbildet und dass die Zielfunktion nach der Trajektorie differenzierbar ist. Die Verwendung einer einheitlichen Funkti- onssignatur für die Zielfunktion ermöglicht den einfachen Austausch von Zielfunktio- nen, ohne den Optimierungsalgorithmus anpassen zu müssen. Die vorgeschlagene Signatur ist ausreichend einfach (Zielfunktion als Bewertung einer Trajektorie mit ei- nem Zahlenwert), um die einfache Implementierung zu gewährleisten, ermöglicht je- doch gleichzeitig die Implementierung nahezu beliebiger Zielfunktionen. Die Differen- zierbarkeit der Zielfunktion nach der Trajektorie ermöglicht den Einsatz gradienten- basierter Optimierungsverfahren für die Parameterinferenz, welche durch die Be- trachtung der Gradienteninformation zielgerichtet in Richtung zumindest lokaler Op- tima konvergieren und daher für viele Klassen von Zielfunktionen deutlich schneller konvergieren als nicht-gradientenbasierte Optimierer.
In vorteilhafter Weise kann die Zielfunktion eine vordefinierte Funktion, eine paramet- rische Funktion und/oder ein neuronales Netz umfassen. Somit sind drei Typen von Zielfunktionen möglich. In vorteilhafter Weise sind diese drei Type auch untereinan- der beliebig kombinierbar. Vordefinierte Funktionen können klassische Prozesskenn- größen wie Zykluszeit oder Pfadlänge betreffen, die eine zu minimierende Größe aus- geben. Parametrische Funktionen können vordefinierte Funktionen umfassen, die weitere, ggf. vom Nutzer, einstellbare Parameter besitzen. Beispiele sind Distanz- funktionen zu Vorgabewerten wie Kontaktkräften, Anzugmomenten oder euklidischen Zielposen. Neuronale Netze können ebenfalls als differenzierbare Funktionsapproxi- matoren für komplexe Zielfunktionen eingesetzt werden.
Beispiele für einfache Zielfunktionen, welche Prozesskenngrößen abbilden, sind Taktzeit, Pfadlänge und/oder Fehlerrate. Weitere komplexere Arten von Zielfunktio- nen können beispielsweise die Einhaltung von Kraftgrenzen, Kraftminimierung bei gleichzeitiger Zykluszeitminimierung, Steigerung der Präzision (z.B. bei stochasti- schen Positionsabweichungen von Werkstücken), Minimierung von Momenten, Vor- gabe bestimmter Kraft- oder Momentenverläufe, etc. betreffen. In vorteilhafter Weise kann die Zielfunktion eine auf Kraftmessung basierte Funktion umfassen. In diesem Fall wird die prädizierte Trajektorie zumindest in Teilen auf- grund der prädizierten Kräfte und Momente bewertet. Dies ist besonders vorteilhaft, da die Optimierung von Programmparameter hinsichtlich über Kräfte definierter Opti- malitätskriterien für menschliche Programmierer sehr schwer ist, da die Zusammen- hänge zwischen Programmparametern und den resultierenden Kräften bei der Pro- grammausführung schwer zu berechnen bzw. durch den Menschen zu verstehen sind. Gerade Programme für Fertigungsprozesse mit kritischen Kontakt- oder Füge- kräften sind für menschliche Programmierer oft schwer zu optimieren, da die anlie- genden Kräfte für den Menschen nicht systematisch berechenbar sind und daher vom Menschen ein durch Ausprobieren unterschiedlicher Parametrierungen ein in der Re- gel suboptimaler Parametersatz gefunden wird. Die automatische Optimierung von Programmparametern kann hier einen besonderen Mehrwert liefern.
In vorteilhafter Weise kann mit der Schnittstelle zum Auswählen eines oder mehrerer kritischer Programmbausteine eine kritische Teilsequenz des Roboterprogramms auswählt werden, wobei die kritische Teilsequenz mehrere kritischen Programmbau- steine umfasst. Die Bausteinrepräsentanten der mehreren kritischen Programmbau- steine können zu einem differenzierbaren Gesamtsystemmodell kombiniert werden. Das Gesamtsystemmodell bildet die Programmparameter der kritischen Teilsequenz auf eine kombinierte Trajektorie ab, so dass für eine zusammenhängende Teilse- quenz von kritischen Programmbausteinen die optimierbaren Programmparameter bezüglich der Zielfunktion optimiert werden. Dies ermöglicht eine ganzheitliche Para- meteroptimierung. Die Programmparameter zusammengehöriger Programmbau- steinsequenzen können gemeinsam optimiert werden. Dies bietet einen Mehrwert ge- genüber lokaler Optimierung auf der Bausteinebene, da Wechselwirkungen mit der Umgebung über Bausteingrenzen hinweg bei der Optimierung betrachtet werden. Insbesondere können widersprüchliche Parameterkonfigurationen zwischen Pro- grammteilen automatisch gegeneinander ausbalanciert werden. Dies ist beispiels- weise der Fall, wenn erhöhte Geschwindigkeit einer Bewegung die Erfolgswahr- scheinlichkeit einer darauffolgenden Bewegung reduziert, zum Beispiel durch Erzeu- gen von Vibrationen oder Verbiegen von Pins bei Kontaktfahrten. Dieser ganzheitli- che Ansatz für die Optimierung von Programmparametern ist von erheblichem Vorteil. Im Rahmen einer vorteilhaften Ausgestaltung eines erfindungsgemäßen Verfahrens können Eingabedaten, Vorgehensweise und Ausgabedaten wie folgt angegeben werden:
1) Eingabedaten:
- Programmstruktur: Typ (zum Beispiel Spiralsuche (Relativ), Kontaktfahrt (Relativ), Greifen, etc.) und sequentielle Ausführungsreihenfolge der kriti- schen Programmbausteine
- Zu optimierende Teilmenge der Programmparameter der kritischen Pro- grammbausteine
- Domäne für jeden zu optimierenden Programmparameter
- Differenzierbare Zielfunktion
2) Vorgehensweise und Datenverarbeitung:
- Explorationsphase: Automatische Abtastung des Parameterraums für je- den kritischen Baustein und Aufzeichnung der resultierenden Roboter- trajektorien
- Lernphase: Erzeugung eines lernbaren Repräsentanten für jeden kritischen Baustein und Training der lernbaren Repräsentanten als Systemmodelle für den in dem zugehörigen Baustein gekapselten Teilprozess
- Inferenzphase: Kombination der gelernten Repräsentanten zu Gesamtsys- temmodellen für jede zusammenhängende Sequenz kritischer Bausteine und Inferenz optimaler Parameter für die vorgegebene Zielfunktion
3) Ausgabedaten:
- Ein optimaler Parametervektor für jeden kritischen Programmbaustein
Als Ergebnis ergibt sich damit ein Roboterprogramm mit hinsichtlich einer vorgege- benen Zielfunktion optimalen bzw. optimierten Parametern.
Vorteilhafte Ausgestaltungen der Erfindung können ein Verfahren und ein entspre- chendes System für die vollautomatische Inferenz optimierter Programmparameter für Industrieroboter bereitstellen, die es während der Programmier-, Inbetriebnahme- und Wartungsphasen von Roboterzellen Roboterprogrammierern oder Werksarbei- tern ermöglicht, die Parameter komplexer Roboterprogramme in Gegenwart von Pro- zess- und Werkstückvarianzen datengetrieben und automatisch auf Taktzeit- und Qualitätsvorgaben hin zu optimieren. Dazu umfasst ein Verfahren bzw. ein System gemäß einem Ausführungsbeispiel der Erfindung Komponenten bzw. Module bzw. Einheiten, die zu einer automatisierten Exploration des Parameterraums, der Modell- bildung, der Spezifikation von Zielfunktionen sowie der Inferenz optimaler/optimierter Parameter dienen. Es kann ein Roboterprogramm mit optimierten Parametern er- reicht werden und demnach eine Roboterzelle mit höherem Durchsatz, höherer Fer- tigungsqualität oder niedrigerem Ausschuss.
Vorteilhafte Ausgestaltungen eines erfindungsgemäßen Verfahrens bzw. eines er- findungsgemäßen Systems können einen oder mehrere der folgenden Vorteile auf- weisen:
- Vollautomatische Parameteroptimierung: Dies hat das Potential, die kostspie- ligen und arbeitsintensiven Perioden des manuellen Fine-Tunings von Pro- grammparametern sowohl während der Inbetriebnahme neuer Roboterzellen als auch bei der Wartung bestehender Roboterzellen durch automatisierte Pa- rameteroptimierung zu ersetzen. Dies spart Personalkosten, je nach Anlage Zeit und die Anlage steht während keiner der drei Phasen des Verfahrens ge- mäß einem Ausführungsbeispiel der Erfindung (Explorationsphase, Lern- phase, Inferenzphase) still. Dies ist im Kontext der Parameteroptimierung für Roboterprogramme von erheblichem Vorteil.
- Auf Realdaten basierende Modellbildung: Im Gegensatz zu simulationsbasier- ten oder rein analytischen Ansätzen ermöglicht ein Ausführungsbeispiel der Erfindung eine Form der Prozessoptimierung basierend auf real gemessenen Daten. Ausführungsbeispiele können insbesondere Prozessoptimierung hin- sichtlich von Zielkräften oder -momente sowie der dynamischen Eigenschaften der Bewegungen ermöglichen, da die gelernten Systemmodelle die Kraftver- läufe der Interaktion des konkreten Roboters in der konkreten Umgebung mit den konkret vorliegenden Werkstücken prädizieren können. Bekannte Verfah- ren zur Prozessoptimierung aus dem Stand der Technik ziehen die real auftre- tenden Kräfte und Momente nicht oder nur begrenzt in Betracht und setzen fundiertes Expertenwissen oder manuelles Trial-and-Error voraus. - Ganzheitliche Parameteroptimierung: Die Parameter zusammengehöriger Programmbausteinsequenzen können gemeinsam optimiert werden. Dies bie- tet einen Mehrwert gegenüber lokaler Optimierung auf der Bausteinebene, da Wechselwirkungen mit der Umgebung über Bausteingrenzen hinweg bei der Optimierung betrachtet werden. Insbesondere können widersprüchliche Para- meterkonfigurationen zwischen Programmteilen des Roboterprogramms auto- matisch gegeneinander ausbalanciert werden. Dies ist zum Beispiel der Fall, wenn erhöhte Geschwindigkeit einer Bewegung die Erfolgswahrscheinlichkeit einer darauffolgenden Bewegung reduziert, zum Beispiel durch Erzeugen von Vibrationen oder Verbiegen von Pins bei Kontaktfahrten. Dieser ganzheitliche Ansatz für die Optimierung von Programmparametern ist in der Industrierobo- tik von erheblichem Vorteil.
- Effiziente Modellbildung und Datenakquise: Im Gegensatz zu bekannten Ver- fahren gemäß dem Stand der Technik zur Lösung von Optimierungsproblemen in der Robotik, die auf realen T rainingsdaten basieren, sind für eine vorteilhafte Ausgestaltung der Erfindung weder überwachte Trainingsdaten noch verstär- kendes Lernen vonnöten. Dies ermöglicht den wirtschaftlichen Einsatz in der Industrie, da der hohe Arbeitsaufwand bei überwachtem Lernen sowie der in der Industrie schwer umsetzbare Nichtdeterminismus verstärkenden Lernens vermieden werden. Die Explorationsphase kann in geplante Inbetriebnahme- bzw. Wartungsphasen der Roboterzelle integriert werden, ermöglicht den un- unterbrochenen produktiven Einsatz der Zelle und bindet keine weiteren Res- sourcen, da keine Überwachung oder manuelles Labelling durch den Werks- arbeiter vonnöten ist.
- Universale Anwendbarkeit: Da ein Ausführungsbeispiel der Erfindung ein tie- fes neuronales Netz als Systemmodell einsetzen kann, trifft das Verfahren ge- mäß dem Ausführungsbeispiel bei der Modellbildung keine Annahmen über die Natur (z.B. parametrische Verteilung, Normalverteilung, Linearität) der Ein- und Ausgabedaten und ist demnach in allen Fertigungsdomänen sowie prinzi- piell für alle Bausteintypen einsetzbar. Da bis auf Differenzierbarkeit keine wei- teren Anforderungen an die Zielfunktion gestellt werden, sind beliebige Ziel- funktionen denkbar. Das Verfahren gemäß dem Ausführungsbeispiel der Er- findung ist somit in beliebigen Anwendungsdomänen wie Montage, Oberflä- chenbearbeitung oder Handling einsetzbar und ermöglicht die Optimierung von Roboterprogrammen hinsichtlich beliebiger Prozesskennzahlen oder Qua- litätskriterien.
Es gibt nun verschiedene Möglichkeiten, die Lehre der vorliegenden Erfindung in vor- teilhafter Weise auszugestalten und weiterzubilden. Dazu ist einerseits auf die dem Anspruch 1 nachgeordneten Ansprüche und andererseits auf die nachfolgende Er- läuterung bevorzugter Ausführungsbeispiele der Erfindung anhand der Zeichnung zu verweisen. In Verbindung mit der Erläuterung der bevorzugten Ausführungsbeispiele der Erfindung anhand der Zeichnung werden auch im Allgemeinen bevorzugte Aus- gestaltungen und Weiterbildungen der Lehre erläutert.
In der Zeichnung zeigen
Fig. 1 ein Aktivitätsdiagramm für ein Verfahren zur Bestimmung von optimier- ten Programmparametern für ein Roboterprogramm gemäß einem Aus- führungsbeispiel der Erfindung,
Fig. 2 ein ergänzendes Aktivitätsdiagramm für das Ausführungsbeispiel ge- mäß Fig. 1 , wobei die in Fig. 1 angedeutete Explorationsphase veran- schaulicht wird,
Fig. 3 ein beispielhaftes Roboterprogramm für eine kraftgeregelte Spiralsu- che, wobei das kritische Teilprogramm solide umrandet ist,
Fig. 4 ein beispielhaftes Roboterprogramm für eine kraftgeregelte Kontakt- fahrt, wobei das kritische Teilprogramm solide umrandet ist,
Fig. 5 in einer schematischen Ansicht eine beispielhafte Systemarchitektur für ein System zur Bestimmung von optimierten Programmparametern für ein Roboterprogramm gemäß einem Ausführungsbeispiel der Erfin- dung, Fig. 6 eine schematische Darstellung des in einer beispielhaften Referenzim- plementierung umgesetzten Datenbankschemas für ein System bzw. ein Verfahren gemäß einem Ausführungsbeispiel der Erfindung,
Fig. 7 eine schematische Darstellung eines differenzierbaren Roboterpro- gramms,
Fig. 8 eine schematische Darstellung eines differenzierbaren Programmbau- steins gemäß einem Ausführungsbeispiel der Erfindung,
Fig. 9 eine schematische Darstellung zur Veranschaulichung eines verein- fachten Berechnungsgraphen eines differenzierbaren Bausteinreprä- sentanten, und
Fig. 10 eine rekurrente Netzarchitektur für ein Ausführungsbeispiel der Erfin- dung.
Fig. 1 und Fig. 2 zeigen ein Aktivitätsdiagramm für ein Verfahren zur Bestimmung von optimierten Programmparametern für ein Roboterprogramm gemäß einem Ausfüh- rungsbeispiel der Erfindung.
Aus Prozesssicht hat das Verfahren gemäß einem Ausführungsbeispiel der Erfindung unterschiedliche Ausprägungen bzw. Anwendungsmöglichkeiten in den Program- mier-, Inbetriebnahme- und Wartungsphasen von Produktionsanlagen bzw. Roboter- zellen. Fig. 1 und Fig. 2 zeigen eine Übersicht über die Verfahrensschritte des Aus- führungsbeispiels, inklusive optionaler Verfahrensschritte, die je nach Ausprägung übersprungen werden können. Generell gibt es in jeder der drei zuvor genannten Phasen im Lebenszyklus einer Anlage bzw. eines Roboters eine mögliche Ausprä- gung des Ausführungsbeispiels. Im Folgenden wird das Verfahren gemäß dem Aus- führungsbeispiel für die Programmier-, Inbetriebnahme- und Wartungsphasen be- schrieben. A. Programmierphase
I. Festlegung der Programmstruktur: Der Roboterprogrammierer erstellt ein Ro- boterprogramm aus parametrierbaren Programmbausteinen (Motion Templates), welche atomare Bewegungen des Roboters abbilden. Das Roboterprogramm besteht aus einer Sequenz beliebiger kraft- oder positionsgeregelter Programmbausteine. Die Sequenz von Programmbausteinen bildet die zur Lösung der Anwendungsaufgabe notwendigen Schritte ab.
- Beispiel Kraftgeregelte Spiralsuche: Fig. 3 zeigt eine schematische Darstel- lung eines beispielhaften semi-symbolischen Roboterprogramms 1 für die kraftgeregelte Spiralsuche. Das kritische Teilprogramm 2 bzw. die kritischen Programmbausteine 3 und 4 des Roboterprogramms 1 sind in Fig. 3 solide umrandet.
- Beispiel Kontaktfahrt: Fig. 4 zeigt eine schematische Darstellung eines bei- spielhaften semi-symbolischen Roboterprogramms 5 für eine kraftgeregelte Kontaktfahrt. Das kritische Teilprogramm 6 bzw. die kritischen Programmbau- steine 7 und 8 des Roboterprogramms 5 sind in Fig. 4 solide umrandet.
Die Ausführungssemantik eines Bausteins vom Typ „Linearbewegung“ 3 bzw. 7 (vgl. Fig. 3 und Fig. 4) kann wie folgt beschrieben werden: Gegeben eine Zielpose sowie eine Geschwindigkeit v und Beschleunigung a, bewege den Roboter derart, dass der Tool-Center-Point (Werkzeugkoordinatensystem des Roboters) eine im kartesischen Raum lineare Bahn von der aktuellen Werkzeugpose zur Zielpose mit der vorgege- benen Geschwindigkeit und Beschleunigung beschreibt.
Die Ausführungssemantik von „Kontaktfahrt (Relativ)“ 8 (vgl. Fig. 4) kann wie folgt beschrieben werden: Gegeben eine Bewegungsvorgabe relativ zur aktuellen Position des Werkzeugkoordinatensystems des Roboters (zum Beispiel „1 Zentimeter Trans- lation in z-Richtung und 3° Rotation um die X-Achse“), eine Kraftvorgabe, welche die Kontaktkraft entlang der Z-Achse des Werkzeugkoordinatensystems vorgibt, sowie eine Geschwindigkeit v und Beschleunigung a, bewege den Roboter auf einer im kar- tesischen Raum linearen Bahn gemäß der Bewegungsvorgabe und mit der vorgege- benen Beschleunigung und Geschwindigkeit, bis die vorgegebene Kraft erreicht wurde. Die Ausführung der Bewegung gilt als erfolgreich, wenn die Kraftvorgabe er- reicht (Kontakt hergestellt) wurde, anderweitig als fehlgeschlagen.
II. Festlegung der initialen Programmparameter: Ein Roboterprogrammierer kann die initialen Parameter der Programmbausteine manuell unter Einsatz gängiger Ver- fahren (Teach-In, CAD to Path, ...) bestimmen, um die Anwendungsaufgabe appro- ximativ (ggf. unter Verletzung der vorgegebenen Taktzeiten und Qualitätsanforderun- gen) zu lösen.
III. Fine-Tuning der Parameter relevanter Teilprogramme: Der Roboterprogram- mierer verwendet ein Verfahren gemäß einem Ausführungsbeispiel der Erfindung für die automatische Optimierung von Programmparametern, um Taktzeitvorgaben und Qualitätsanforderungen zu erfüllen.
III. a. Auswahl kritischer Teilprogramme: Der Roboterprogrammierer wählt kritische Teilsequenzen des Programms (d.h. kritische Teilprogramme) oder einzelne kritische Programmbausteine aus, deren Programmparameter optimiert werden sollen.
- Beispiel Kraftgeregelte Spiralsuche: Hier besteht das kritische Teilprogramm 2 aus der Sequenz [„Linearbewegung“, „Spiralsuche (Relativ)“], da die Parame- ter der Linearbewegung (insbesondere deren Zielpose) die Position und Ori- entierung der Spiralsuche grundlegend beeinflussen (vgl. Fig. 3).
- Beispiel Kontaktfahrt: Hier besteht das kritische Teilprogramm 6 aus der Se- quenz [„Linearbewegung“, „Kontaktfahrt (Relativ)“], da insbesondere die Z-Ko- ordinate der Zielpose der Linearbewegung die erwartete Länge der Kontakt- fahrt grundlegend beeinflusst (vgl. Fig. 4).
III. b. Auswahl der zu optimierenden Parameter: In Abhängigkeit von Umgebung und Anwendungsaufgabe sind bestimmte Programmparameter der kritischen Teilpro- gramme bzw. der kritischen Programmbausteine als Konstanten zu markieren, um Sicherheit oder Qualitätsanforderungen zu gewährleisten. Dies betrifft zum Beispiel Zielposen von Bewegungen in Bereichen der Roboterzelle mit eingeschränkter Er- reichbarkeit oder Kraftunter- bzw. -obergrenzen kraftgeregelter Bewegungen. Die De- signation konstanter Parameter ist anwendungsspezifisch und erfordert Domänen- wissen, kann jedoch in vielen Fällen bereits beim Zellentwurf unter Zuhilfenahme der CAD-Modelle der Zelle, ggf. verwendeter Prozesssimulationssoftware sowie Offline- Robotersimulationssoftware bestimmt werden.
- Beispiel Kraftgeregelte Spiralsuche: Bei Spiralsuchbewegungen sind vor allem Geschwindigkeit und Beschleunigung, aber auch die Ausdehnung der Spirale entlang ihrer Hauptachsen, die Orientierung der Spirale sowie der Abstand zwischen den Windungen für den Erfolg der Suchaktion entscheidend und sind daher zu optimieren. Zudem ist die Z-Komponente der Orientierung der Ziel- pose der zuvorkommenden Linearbewegung (in Tait-Bryan-Winkeln) relevant, da diese die Orientierung der (planaren) Spirale vorgibt. Die Parameter [Aus- dehnung (X), Ausdehnung (Y), Abstand Spiralarme, v, a] von „Spiralsuche (Re- lativ)“ sowie die Z-Rotationskomponente des Zielpose-Eingangs der Linearbe- wegung sind daher optimierbar, alle übrigen Parameter werden als konstant markiert (vgl. Fig. 3).
- Beispiel Kontaktfahrt: Um Kraftgrenzen nicht zu überschreiten, sind insbeson- dere Geschwindigkeit und Beschleunigung maßgebend. Die Z-Komponente der vorgeschalteten Linearbewegung bestimmt zusammen mit der Lage des Werkstücks die Länge der Kontaktfahrt. Optimierbare Parameter sind hier [v, a] von „Kontaktfahrt (Relativ)“ sowie die z-Koordinate des Zielpose-Eingangs von „Linearbewegung“ (vgl. Fig. 4).
Programmparameter eines Programmbausteins können entweder Eingabe- (Zielpo- sen, Zielkräfte etc.) oder intrinsische Parameter (Geschwindigkeit, Beschleunigung) sein. Beide Parametertypen können optimiert werden.
III. c. Festlegung der Domäne für optimierbare Parameter: Der Roboterprogrammie- rer kann für jeden zu optimierenden bzw. optimierbaren (d.h. nicht konstanten) Pro- grammparameter der kritischen Teilprogramme bzw. der kritischen Programmbau- steine einen zulässigen Wertebereich wählen, über welchen optimiert werden soll. Dieser ist anwendungsspezifisch und in der Regel ausreichend schmal, sodass alle Sicherheitsanforderungen an den Fertigungsprozess sowie Mindestanforderungen an Qualität und Zykluszeit erfüllt werden. - Beispiel Kraftgeregelte Spiralsuche: Die Geschwindigkeits- und Beschleuni- gungsgrenzen erfolgreicher Spiralsuchen sind stark abhängig von Roboter und Umgebung, liegen aber in der Regel im Bereich [0.001m/s, 0.005m/s] bzw. [0.001m/s2, 0.05m/s2]. Die erwartete Streuung der Lochpositionen liegt typi- scherweise im Millimeterbereich, entsprechend werden die Grenzen für die Ausdehnung und den Windungsabstand der Spirale festgelegt. Die Domäne der Tait-Bryan-z-Komponente der Zielpose der Linearbewegung ist aufgrund der annähernden Punktsymmetrie der Spirale [0, 180°] (vgl. Fig. 3).
- Beispiel Kontaktfahrt: Hier ist die korrekte Einschränkung der Geschwindig- keitsdomäne sicherheitskritisch, da bei schnellen Kontaktfahrten beliebig große Kräfte auftreten können, bevor der Kraftregler die Bewegung abbricht. Ebenfalls muss durch Einschränkung der Domäne eine Kollision mit dem Werkstück während der Ausführung der Linearbewegung verhindert werden (vgl. Fig. 4).
III. d. Explorationsphase: Es erfolgt eine automatische, stochastische Exploration des Parameterraums. Das Roboterprogramm wird nun unter realistischen Bedingun- gen, jedoch noch nicht in der Produktivumgebung wiederholt (zum Beispiel 1000 < N < 10000) automatisiert ausgeführt. Hierbei werden für jede Ausführung die zu opti- mierenden Programmparameter aus ihrer jeweiligen Domäne gesampelt. Zum Bei- spiel über ein gleichverteiltes Sampling. Während der Ausführung werden die Posi- tion und Orientierung des Tool-Center-Points (TCP) des Roboters sowie die am TCP auftretenden Kräfte und Momente in einem beliebigen, aber festen Abtastintervall (8 ms < At < 100 ms) abgetastet und in einer Datenbank gespeichert. Zusätzlich werden zu den Daten jedes ausgeführten Programmbausteins eine ID, mit welcher der Pro- grammbaustein im Roboterprogramm identifiziert werden kann, sowie ein Statuscode vom Roboter an die Datenbank übertragen. Der Statuscode identifiziert gemäß der Semantik des Programmbausteins, ob die ausgeführte Aktion erfolgreich beendet wurde. Kraftgeregelte Fahrten auf Kontakt enden zum Beispiel erfolgreich, wenn Kon- takt hergestellt wurde und die Kontaktkraft innerhalb eines eingestellten Toleranzbe- reichs liegt. Zudem werden die zufällig generierten Programmparameter in der Da- tenbank gespeichert und mit der Programmausführung assoziiert. Das Abtastintervall At ist anwendungsspezifisch und kann vom Programmierer vorgegeben werden. Große Abtastintervalle reduzieren die zu verarbeitenden und zu speichernden Daten- mengen und vereinfachen das Lernproblem, sodass weniger Programmausführun- gen (N) notwendig sind, führen jedoch bei hochfrequenten oder schwingenden Pro- zessen zu Aliasing und Unterabtastung. Die Zahl der Programmausführungen N ist ebenfalls anwendungsspezifisch und hängt von der Komplexität und Länge der Ro- boterbewegungen, der (Nicht-)Linearität der Kraft- und Momentenverläufe bei Inter- aktionen des Roboters mit der Umgebung sowie der Stochastizität des Prozesses ab. Falls Werkstückvarianzen erwartet werden, sollten während der Explorationsphase Werkstücke unterschiedlicher Chargen verwendet werden, um die Werkstückvarian- zen mit einzulernen.
III. e. Lernphase: Es erfolgt ein automatisches Training der Systemmodelle. Für je- den Programmbaustein der kritischen Teilprogramme wird auf Basis der zuvor ge- sammelten Parametersätze und Trajektorien ein Systemmodell gelernt, welches die Bausteinparameter auf die erwarteten Positionen und Orientierungen des TCP, die erwarteten Kräfte und Momente sowie den erwarteten Statuscode abbildet. Für das Training ist keine Nutzerinteraktion notwendig. Die Trainingsdauer ist abhängig von der Anzahl und Komplexität der Programmbausteine sowie von der Anzahl, Länge und Abtastcharakteristik der Trajektorien im Trainingsdatensatz.
In diesem Kontext kann ein „SystemmodeN“ definiert sein als eine mathematische Funktion /, die gegeben den Eingabeparametern x und dem Systemzustand p die erwartete Trajektorie Ϋ ausgibt. / beinhaltet somit implizit die Programmlogik (die Übersetzung von x in Steuerbefehle für den Roboter durch das Roboterprogramm), die Kinematik und Dynamik des Roboters, und die physikalischen Eigenschaften der Umgebung.
Ill.f. Spezifikation der Zielfunktion: Eine beliebige Zielfunktion wird festgelegt, be- züglich welcher die Programmparameter optimiert werden sollen. Jede Zielfunktion ist valide, sofern sie eine Trajektorie auf eine rationale Zahl abbildet und nach der Trajektorie differenzierbar ist. Konkave Zielfunktionen vereinfachen das Optimie- rungsproblem, da sie nur ein (globales) Maximum aufweisen und das Ergebnis der Optimierung unabhängig von der initialen Parametrierung ist. Für nicht konkave Ziel- funktionen mit lokalen Maxima ist die Optimierung sensitiv gegenüber der initialen Parametrierung. Beliebige Zielfunktionen können durch gewichtete Addition kombi- niert werden, wobei durch die Addition lokale Maxima entstehen können. Durch den Einsatz iterativer Monte Carlo-Verfahren kann die Konvergenz der Optimierung auf global optimale Parametersätze, gegeben der Korrektheit des gelernten Systemmo- dells, asymptotisch garantiert werden. Die Spezifikation der Zielfunktion ist anwen- dungsspezifisch und muss gegebenenfalls von einem Experten in der jeweiligen Fer- tigungsdomäne vorgenommen werden. Für die Optimierung wird ein gradientenba- siertes Optimierungsverfahren eingesetzt und die Zielfunktion als Loss-Funktion (Ver- lust-Funktion) für das äquivalente Minimierungsproblem ausgedrückt. Beispielhafte einfache Loss-Funktionen sind die Zykluszeit, die Pfadlänge im kartesischen oder Konfigurationsraum oder die Fehlerwahrscheinlichkeit. Komplexe Loss-Funktionen sind die Distanz zu einer oder mehrerer Referenztrajektorien, zum Beispiel aus De- monstrationen des Menschen, oder die Abweichung von vorgegebenen Kontaktkräf- ten am Ende einer Trajektorie oder während der Ausführung eines Programmbau- steins. Eine initiale Zielfunktion kann durch Inferenz über eine Wissensbasis aus der Semantik der Bausteine der kritischen Programmteile automatisch erzeugt und durch eine grafische Benutzerschnittstelle durch den Programmierer angepasst werden.
- Beispiel Kraftgeregelte Spiralsuche: Durch Spezifikation einer kombinierten Loss-Funktion aus Fehlerwahrscheinlichkeit und Zykluszeit oder Pfadlänge können kraftgeregelte Spiralsuchbewegungen auf die optimale Balance zwi- schen Taktzeit- und Ausschussminimierung optimiert werden. Hinsichtlich des gelernten Systemmodells resultiert die Optimierung in Parametern, welche die Radien entlang der Hauptachsen, Abstand der Windungen, Orientierung, Ge- schwindigkeit und Beschleunigung optimal abwägen.
- Beispiel Kontaktfahrt: Kraftgeregelte Kontaktfahrten können durch Spezifika- tion einer Loss-Funktion proportional zur Distanz der prädizierten Kraft entlang der Z-Achse zu einer vorgegebenen Zielkraft in ihren dynamischen Eigen- schaften dahingehend optimiert werden, dass im Mittel die Zielkraft möglichst exakt erreicht wird.
III. g. Inferenzphase: Es erfolgt eine automatische Optimierung der Programmpara- meter. Für jedes kritische Teilprogramm werden die gelernten Systemmodelle der zugehörigen Programmbausteine automatisch zu einem Gesamtmodell kombiniert, welches die Parameter des Teilprogramms auf die kombinierte Teiltrajektorie abbil- det. Ein gradientenbasierter Optimierungsalgorithmus optimiert iterativ die Pro- grammparameter bezüglich der vorgegebenen Zielfunktion. Die optimierten Parame- ter werden automatisch in das Roboterprogramm übertragen.
- Beispiel Kraftgeregelte Spiralsuche: Bei Spiralsuchbewegungen führen glo- bale Optima der Parameter in der Regel zu einer maximalen Abdeckung der Wahrscheinlichkeitsmasse der erwarteten Lochverteilungen bei gleichzeitiger Maximierung von Geschwindigkeit und Beschleunigung bis zu dem Punkt, an dem weitere Steigerungen der Geschwindigkeit zu große Einbußen bei der Fehlerrate bedeuten. Die Orientierung der Hauptachsen der Spirale werden an die Hauptachsen der Lochverteilung angepasst.
- Beispiel Kontaktfahrt: Die Geschwindigkeits- und -Beschleunigungsparameter von Kontaktfahrten garantieren nach der Optimierung die größtmögliche Wahr- scheinlichkeit, die angegebene Zielkontaktkraft zu erreichen und nicht zu über- schreiten. Bei gleichzeitiger Taktzeitminimierung wird die Länge der Kontakt- fahrt durch Absenkung der Zielposition der zuvorkommenden Linearbewegung minimiert.
IV. Manuelle Abnahme durch den Programmierer/Nutzer: Der Roboterprogram- miererführt das optimierte Roboterprogramm wiederholt aus und stellt die Einhaltung aller Sicherheits-, Taktzeit- und Qualitätsanforderungen sicher. Ggf. werden quanti- tative, statistische Methoden für die Messung und Prozesskenngrößen eingesetzt.
B. Inbetriebnahmephase
I. Anpassung von Programmparametern während dem Ramp-Up: Nach der In- tegration der Roboterzelle in die übrige Fertigungslinie läuft die Produktion in der Re- gel mit niedrigerer Qualität, reduzierter Stückzahl oder höherem Ausschuss an. Grund hierfür sind häufig minimale Abweichungen der Umgebung, der Werkstücke oder des Aufbaus gegenüber der Programmierphase. Gängige Praxis ist die manuelle, iterative Anpassung der Programmparameter, um den Prozess wieder in die vorgegebenen Taktzeit- und Qualitätsgrenzen zu bringen. Bestehende Werkzeuge zur automati- schen Prozessoptimierung oder zum Tuning von Reglerparametern automatisieren den Optimierungsprozess nur teilweise und nur für bestimmte Parameter bzw. Bewe- gungen. Der Werker kann unter Einsatz einer vereinfachten Version des unter A.lll beschriebenen Vorgehens die Parameter des Roboterprogramms vollautomatisch an die veränderten Gegebenheiten anpassen. Schritte A.lll.a bis A.lll.c können über- sprungen werden, da die dort eingestellten Hyperparameter des Verfahrens robust gegenüber stochastischen Änderungen des Systems bzw. der Umgebung sind. Die Anzahl der benötigten Trainingsdaten (vgl. A.lll. d) ist um Faktor 10-20 geringer als in der Programmierphase, da die bestehenden Systemmodelle unter Einsatz von Trans- fer-Learning-Verfahren auf die geänderte Umgebung nachkonditioniert werden kön- nen. Schritt A.lll.f kann in vielen Fällen ebenfalls übersprungen werden, sollten sich die Taktzeit- und Qualitätsvorgaben gegenüber der Programmierphase nicht geän- dert haben. Hier besteht jedoch die Möglichkeit, auch die Zielfunktion auf die geän- derten Gegebenheiten im Werk anzupassen.
- Beispiel Kraftgeregelte Spiralsuche: Bei der Inbetriebnahme stellt der Integra- tor fest, dass in der Produktion Bauteile von einem anderen Hersteller verbaut werden als jene, für die die Roboterzelle bei der Programmierung feineinge- stellt wurde. So weist beispielsweise die mittlere Orientierung der Pins von Elektronikkomponenten im Vergleich zur Programmierphase einen stochasti- schen Offset um bis zu 2° auf, wodurch eine große Anzahl an Suchbewegun- gen fehlschlagen und die Taktzeitvorgaben nicht mehr eingehalten werden können. Durch Nachtraining des Systemmodells und Parameterinferenz kann die Verteilung des Offsets implizit geschätzt und durch die neuen Programm- parameter kompensiert werden.
- Beispiel Kontaktfahrt: Bei der Inbetriebnahme stellt der Werksarbeiter fest, dass bedingt durch den Transport der Zelle die Positionierung der zu bestü- ckenden Platinen im Mittel um 1mm in derZ-Richtung von der erwarteten Höhe abweicht, wodurch Kontaktfahrten zum Setzen von Bauteilen im Schnitt 0.5s länger dauern. Durch Nachtraining des Systemmodells und Parameterinferenz kann die ursprüngliche Zykluszeit wiederhergestellt werden. C. Wartungsphase/Serienproduktion
I. Kompensation von Prozess- und Werkstückvarianzen: Während der laufenden Produktion können Veränderungen der Umgebung, der Produktionsanlage oder der Werkstücke auftreten. Bei einem Hersteller- oder Chargenwechsel können Bauteile andere Oberflächen- oder Biegeeigenschaften haben. Zudem kann sich das System- verhalten durch Wartungsarbeiten an der Anlage, Austausch von Motoren und Sen- sorik oder Verschleißeffekte über die Einsatzzeit der Anlage hinweg ändern. Unter Einsatz einer vereinfachten Version des unter A.lll beschriebenen Vorgehens kann der Werker die Parameter des Roboterprogramms vollautomatisch an die veränder- ten Gegebenheiten anpassen. Schritte A.lll.a bis A.lll.c können übersprungen wer- den, da die dort eingestellten Hyperparameter des Verfahrens robust gegenüber stochastischen Änderungen des Systems bzw. der Umgebung sind. Die Anzahl der benötigten Trainingsdaten (vgl. A.lll.d) ist um Faktor 10-20 geringer als in der Pro- grammierphase, da die bestehenden Systemmodelle unter Einsatz von Transfer- Learning-Verfahren auf die geänderte Umgebung nachkonditioniert werden können. Schritt A.lll.f kann bei gleichgebliebenen Taktzeit- und Qualitätsvorgaben ebenfalls übersprungen werden.
- Beispiel Kraftgeregelte Spiralsuche: Bedingt durch Verschleißeffekte des Po- sitionierungssystems der zu bestückenden Elektronikplatinen ist die Varianz der Loch-positionen nach längerem Produktivbetrieb der Anlage signifikant ge- stiegen, sodass die Platinen nicht mehr zuverlässig bestückt werden können. Durch die erneutes Nachtraining des Systemmodells kann die neue Lochver- teilung implizit geschätzt und durch Parameterinferenz die Spiralsuchbewe- gungen nachparametriert werden, um durch Vergrößerung der Suchregion und Verfeinerung des Suchrasters die Qualitätsvorgaben einzuhalten.
II. Adaption an neue Zielvorgaben: Falls sich zum Beispiel aufgrund von Umkon- figurationen an anderen Stellen der Produktionslinie Taktzeitvorgaben oder Qualitäts- anforderungen ändern, kann der Werker durch Ausführen von Schritten A.lll.f und A.lll.g durch Spezifikation einer entsprechenden Zielfunktion die Parameter des Ro- boterprogramms an die neuen Vorgaben anpassen. Die bestehenden Systemmodelle behalten ihre Gültigkeit und können ohne erneutes Training wiederverwendet wer- den. - Beispiel Kontaktfahrt: Aufgrund eines Zuliefererwechsels sind die Pins der ver- bauten Elektronikkomponenten weniger belastbar als zuvor und verbiegen sich bei der aktuell vorgesehenen Kontaktkraft. Durch Reduktion der Kraftvor- gabe der korrespondierenden Zielfunktion und erneute Parameterinferenz ohne Nachtrainieren kann eine neue Parametrierung gefunden werden, wel- che die neue, niedrigere Kontaktkraft gewährleistet.
Fig. 5 zeigt in einer schematischen Ansicht eine beispielhafte Systemarchitektur mit einzelnen Systemkomponenten für ein System zur Bestimmung von optimierten Pro- grammparametern für ein Roboterprogramm gemäß einem Ausführungsbeispiel der Erfindung.
System komponenten: a. Roboterzelle 9 mit sechsachsigem industriellem Manipulator: Es wird die Mög- lichkeit vorausgesetzt, Kräfte und Momente am TCP zu messen. Hierzu ist ggf. ein externer Kraft-Momenten-Sensor notwendig. b. Bausteinbasiertes grafisches Programmiersystem 10 zur Programmierung und Ausführung von Roboterprogrammen: Für die Erstellung des initialen Roboterpro- gramms, dessen Parametrierung sowie dessen Ausführung auf dem Robotercontrol- ler wird ein Softwaresystem mit grafischer Benutzerschnittstelle benötigt, welches semi-symbolische Roboterprogramme bearbeiten, in ausführbaren Robotercode kompilieren und auf dem Robotercontroller ausführen kann. c. Datenbank 11 für Roboterprogramme und -trajektorien: In der Datenbank 11 werden Roboterprogramme in einem Format serialisiert abgespeichert, welches die Rekonstruktion der Programmstruktur und Parametrierung ermöglicht (Ausführungs- reihenfolge, Typ und eindeutige IDs der Programmbausteine, konstante und optimier- bare Parameter der Programmbausteine). Für jede Ausführung des Roboterpro- gramms enthält die Datenbank eine abgetastete Trajektorie bestehend aus Position und Orientierung des TCP, Kräften und Momenten am TCP sowie dem Statuscode des zu dem Datenpunkt gehörenden Programmbausteins. Das Speicherformat ist derart, dass jedem Datenpunkt einer Trajektorie der dazugehörige Programmbau- stein sowie die Parametrierung des Programmbausteins zum Zeitpunkt der Ausfüh- rung eindeutig zugeordnet werden kann. Fig. 6 zeigt eine schematische Darstellung des in einer beispielhaften Referenzimplementierung umgesetzten Datenbanksche- mas. d. Lernsystem 12 für differenzierbare Bausteinrepräsentanten: Das Lernsystem 12 transformiert eine serialisierte Repräsentation der Programmstruktur der kritischen Teilprogramme in einen Satz differenzierbarer (parameteroptimierbarer) Bewegungs- primitive. Jedes differenzierbare Bewegungsprimitiv ist hierbei ein funktional äquiva- lentes Analog („Repräsentant“, „SystemmodeN“) zu einer Bausteininstanz aus dem Teilprogramm, welches die Parameter der Bausteininstanz auf eine bei der Ausfüh- rung erwartete Trajektorie abbildet.
Ein Bausteinrepräsentant ist definiert als ein Systemmodell auf Bausteinebene bzw. ein Modell der Ausführung des korrespondierenden Programmbausteins. Ein Bau- steinrepräsentant für Programmbaustein B ist demnach eine mathematische Funktion fB, die gegeben den Eingabeparametern xB des Programmbausteins und dem Sys- temzustand p die erwartete Trajektorie YB ausgibt, die bei der Ausführung des Pro- grammbausteins auf dem Roboter resultieren wird. Bausteinrepräsentanten sind demnach mathematische Modelle der Ausführung von Programmbausteinen. Diese Modelle können anhand von Trainingsdaten gelernt werden und sind differenzierbar, d.h. sie ermöglichen die Berechnung der Ableitung von YB nach xB. Dies erlaubt die Optimierung von xB mit gradientenbasierten Optimierungsverfahren. Da alle Bau- steinrepräsentanten ableitbare Modelle der Ausführung von Programmbausteinen sind, ist auch ein gemäß Fig. 7 zusammengesetztes Programm aus Bausteinreprä- sentanten differenzierbar und ermöglicht die gemeinsame Optimierung der Parame- ter aller enthaltenen Bausteinrepräsentanten für eine Zielfunktion über der gesamten Trajektorie. Diese differenzierbare und damit optimierbare Darstellung von Roboter- programmen ist die Grundlage eines Optimierungsverfahrens für Programmparame- ter gemäß einem Ausführungsbeispiel der Erfindung. e. Wissensbasis bzw. Ontologie 13 über bausteinspezifische Teilziele: In vielen Fällen enthält die Zielfunktion für die Parameteroptimierung Teilziele, die sich direkt aus der Ausführungssemantik der Bausteintypen ergibt. Eine kraftgeregelte Kontakt- fahrt hat beispielsweise ein implizites Kontaktziel in einem vorgegebenen Kraftbe- reich. Diese impliziten Teilziele werden in einer Wissensbasis in Form einer Ontologie abgespeichert. Zum Zeitpunkt der Spezifikation der Zielfunktion wird durch Reason- ing über der Ontologie eine initiale Zielfunktion aus der gegebenen Programmstruktur erstellt, welche diese impliziten Teilziele abbildet. Diese kann vom Anwender ange- passt und um weitere, anwendungsspezifische Teilziele ergänzt werden. Die Nutzung von Ontologien bzw. Wissensbasen zum automatischen Bootstrapping von Zielfunk- tionen stellt einen wesentlichen Vorteil dar.
Eine Ontologie ist eine strukturierte Darstellungsform für Informationen mit logischen Relationen (eine Wissensdatenbank), welche es ermöglicht, mit geeigneten Verarbei- tungsalgorithmen aus den in der Ontologie enthaltenen Informationen logische Schlüsse zu ziehen (Reasoning).
Die meisten Ontologien folgen dem OWL-Standard (https://www.w3.org/OWL/). Bei- spiele für Ontologien sind BFO (https://basic-formal-ontology.org/) oder LapOntoSPM (https://pubmed.ncbi.nlm.nih.gov/26062794/). Das verbreitetste Softwareframework für Reasoning ist HermiT (http://www.hermit-reasoner.com/). OWL und HermiT kön- nen im Rahmen einer beispielhaften Implementierung gemäß einem Ausführungsbei- spiel verwendet.
In einer beispielhaften Referenzimplementierung gemäß einem Ausführungsbeispiel der Erfindung bildet die entwickelte Ontologie eine „Datenbank für vordefinierte Ziel- funktionen“, auf welcher durch Reasoning aus einem gegebenen semi-symbolischen Roboterprogramm automatisch Zielfunktionen abgeleitet werden können, die auf- grund der festen Semantik der Programmbausteine immer gelten müssen, z.B. dass ein „Kontaktfahrt (Relativ)“-Baustein eine Kontaktkraft entlang der Z-Achse des Werk- zeugkoordinatensystems hersteilen sollte oder dass bei einem „Linearbewegung“- Baustein der Zielpunkt möglichst genau erreicht werden soll. Dies reduziert die Auf- gabe der Spezifikation der Zielfunktion für den Nutzer auf die Aspekte der Zielfunk- tion, die nicht schon aus der Semantik der Programmbausteine folgen, sondern z.B. aus der Anwendung (Kontaktkräfte, Geschwindigkeiten, ...) oder aus betriebswirt- schaftlichen Gründen (Minimierung der Zykluszeit, ...). f. System 14 zur Spezifikation differenzierbarer Zielfunktionen: Differenzierbare Zielfunktionen werden softwareseitig zunächst durch Reasoning über die Wissensba- sis der bausteinspezifischen Teilziele vorberechnet und können ggf. anschließend vom Nutzer unter Verwendung einer Schnittstelle bearbeitet werden. Die resultie- rende interne Repräsentation der kombinierten Zielfunktion wird anschließend in ei- nen differenzierbaren Berechnungsgraphen der Loss-Funktion für das äquivalente Minimierungsproblem übersetzt.
Es sind drei Typen von Zielfunktionen möglich und untereinander beliebig kombinier- bar:
- Vordefinierte Funktionen: Klassische Prozesskenngrößen wie Zykluszeit oder Pfadlänge, die eine zu minimierende Größe ausgeben. Sind bei Verwendung der o.g. Nutzerschnittstelle lediglich vom Nutzer auszuwählen.
- Parametrische Funktionen: Vordefinierte Funktionen, die weitere vom Nutzer einstellbare Parameter besitzen. Beispiele sind Distanzfunktionen zu Vorga- bewerten wie Kontaktkräften, Anzugmomenten oder euklidischen Zielposen. Die Vorgabewerte sind über eine Schnittstelle vom Nutzer einstellbar.
- Neuronale Netze: Da beliebige differenzierbare Funktionen als Zielfunktionen einsetzbar sind, können auch neuronale Netze als differenzierbare Funktions- approximatoren für komplexe Zielfunktionen eingesetzt werden. g. Inferenzsystem 15 für optimale Roboterparameter: Das Inferenzsystem 15 bil- det unter Betrachtung der spezifizierten Zielfunktion sowie der trainierten Bausteinre- präsentanten einen Ende-zu-Ende-optimierbaren Berechnungsgraphen für jedes kri- tische Teilprogramm. Auf diesem Graphen berechnet der Inferenzalgorithmus die für die spezifizierte Zielfunktion optimalen Programmparameter. Dieses System ist in sei- ner Ausprägung sowie der Anwendung in der Industrierobotik neu.
Externe Schnittstellen:
Grafische Benutzerschnittstelle zur Erstellung, Bearbeitung und Ausführung von Roboterprogrammen: Eine grafische Benutzerschnittstelle für die initiale Erstellung und manuelle Bearbeitung von Programmstruktur und -parametrie- rung wird vorgesehen. In einer beispielhaften Referenzimplementierung eines Verfahrens gemäß einem Ausführungsbeispiel wird die ArtiMinds Robot Pro- gramming Suite (RPS) als Schnittstelle verwendet, um Roboterprogramme in der semi-symbolischen ArtiMinds Robot Task Model (ARTM)-Repräsentation zu erstellen und zu parametrieren. Die Benutzerschnittstelle stellt zudem Inf- rastruktur zur Ausführung geladener Roboterprogramme auf dem Robotercon- troller bereit.
- Maschinelle Schnittstelle zum Lesen, Schreiben und Speichern von Roboter- programmstruktur und -parametrierung sowie Versionierung: In der Lernphase wird der Parameterraum zufällig abgetastet und die parametrierten Roboter- programme versioniert in einer Datenbank gespeichert (vgl. Systemkompo- nente a.). Um diesen Prozess zu automatisieren, ist eine maschinelle Schnitt- stelle vorgesehen, um von dem Lern-Framework generierte Parametersätze in das Roboterprogramm einzuspielen, und das parametrierte Roboterprogramm nach der Ausführung versioniert in einer Datenbank zu persistieren, um zum Trainingszeitpunkt die resultierende Trajektorie mit der Programmstruktur und -parametrierung zu assoziieren. In der beispielhaften Referenzimplementie- rung erfüllt das Control Plugin der ArtiMinds RPS diese Funktion.
- Maschinelle Schnittstelle zur Aufzeichnung von Robotertrajektorien: Die aus- geführten Robotertrajektorien werden abgetastet. Die auf dem Robotercontrol- ler auslesbaren Positions-, Orientierungs-, Kraft- und Momentendaten werden geometrisch in Pose, Kräfte und Momente am TCP in Weltkoordinaten trans- formiert. Nach der Ausführung jedes Bausteins wird auf dem Robotercontroller ein boolescher Wert berechnen, welcher angibt, ob der Baustein erfolgreich ausgeführt wurde. Diese Daten werden über eine maschinelle Schnittstelle in eine Datenbank übertragen. Datenbank sowie Schnittstellen werden in der bei- spielhaften Referenzimplementierung von der ArtiMinds RPS und LAR (Lear- ning and Analytics for Robots) bereitgestellt.
Benutzerschnittstelle zur Erstellung und Bearbeitung differenzierbarer Ziel- funktionen: Die beispielhafte Referenzimplementierung umfasst ein konsolen- basiertes Dialogsystem, über welches der Nutzer interaktiv die aus der Wis- sensbasis vorberechneten Teilziele anpassen und um weitere Teilziele ergän- zen kann.
Im Rahmen eines Ausführungsbeispiels der Erfindung können folgende Phasen - nämlich Explorationsphase, Lernphase und Inferenzphase - ausgeführt und imple- mentiert werden, wobei Komponenten dieses Ausführungsbeispiel durch Fig. 8, Fig. 9 und Fig. 10 veranschaulicht wird:
Explorationsphase:
Automatische Abtastung des Parameterraums: Das automatische, zufällige Samplen von Parameterkonfigurationen (bzw. der optimierbaren Programmparameter) aus de- ren jeweiligen Domänen wurde in einer beispielhaften Referenzimplementierung über die externe Programmierschnittstelle der ArtiMinds Robot Programming Suite umge- setzt.
Lemphase:
Erzeugung eines lernbaren Repräsentanten für jeden kritischen Baustein: Kern eines Systems gemäß dem Ausführungsbeispiel ist eine Repräsentation von Programm- bausteinen, welche die gradientenbasierte Optimierung der Parameter bezüglich ei- ner Zielfunktion zulässt. Grundlegend wird das Inferenzproblem optimaler Parameter in eine Lernphase und eine Inferenzphase aufgeteilt, wobei in der Lernphase ein Mo- dell des Systems (Roboter und Umgebung während der Ausführung eines Bausteins) gelernt wird und in der Inferenzphase ein gradientenbasierter Optimierungsalgorith- mus unter Einsatz des gelernten Systemmodells die Eingabeparameter des Baustein- repräsentanten optimiert.
Bausteinrepräsentanten bilden die Bausteinparameter auf eine erwartete Trajektorie ab und garantieren die Differenzierbarkeit der ausgegebenen Trajektorie nach den Bausteinparametern. Diese Abbildung wird mithilfe eines rekurrenten neuronalen Netzes realisiert. Da insbesondere lange, fein abgetastete Trajektorien viel redun- dante Information enthalten und bei der Prädiktion mit neuronalen Netzen große Se- quenzlängen das Lernproblem deutlich erschweren, wird dem neuronalen Netz ein analytischer Trajektoriengenerator vorgeschaltet, welcher eine priore Trajektorie er- zeugt (vgl. Fig. 8). In einer Referenzimplementierung des Verfahrens gemäß dem Ausführungsbeispiel besteht der Trajektoriengenerator aus einer differenzierbaren Implementierung eines Offline-Robotersimulators. Die priore Trajektorie entspricht ei- ner generischen Ausführung des Programmbausteins ohne Betrachtung der Umge- bung, d.h. in einem künstlichen Raum mit Nullkräften und unter idealisierter Roboter- kinematik und -dynamik, ausgehend von einem gegebenen Startzustand. Diese starke Priore (strong prior) wird mit den Bausteinparametern zu einer augmentierten Eingabesequenz für das neuronale Netz kombiniert. Das Netz wird darauf trainiert, das Residuum zwischen priorer und posteriorer (d.h. real gemessener) Trajektorie sowie die Erfolgswahrscheinlichkeit der Bausteinausführung zu prädizieren (vgl. Fig. 8 sowie den vereinfachten Berechnungsgraphen in Fig. 9).
Die Addition von Residuum und Priore ergibt die ausgegebene erwartete posteriore Trajektorie für diesen Progammbaustein und die gegebenen Bausteinparameter. Die Vereinfachung des Lernproblems beim Training neuronaler Netze durch die Einfüh- rung starker Priore ist etablierte Praxis. Algorithmische Priore können sowohl durch spezifische Netzstruktur (vgl. R. Jonschkowski, D. Rastogi, und O. Brock, „Differenti- able Particle Filters: End-to-End Learning with Algorithmic Priors“, ArXivI 80511122 Cs Stat, Mai 2018, Zugegriffen: Apr. 03, 2020. [Online] Verfügbar unter: http://ar- xiv.org/abs/1805.11122) als auch durch Darstellung der Ausgabewerte als Parameter zuvor festgelegter parametrischer Wahrscheinlichkeitsverteilungen sein (vgl. den Ein- satz von Gaußprozessen zum Beispiel in M. Y. Seker, M. Imre, J. Piater, und E. Ugur, „Conditional Neural Movement Primitives“, S. 9) oder Gaußmixturen in A. Graves, „Generating Sequences With Recurrent Neural Networks“, ArXivI 3080850 Cs, Juni 2014, Zugegriffen: Nov. 22, 2019. [Online] Verfügbar unter: http://ar- xiv.org/abs/1308.0850). Im vorliegenden Fall werden Aspekte des Geschwindigkeits- profils, die Grobverortung im Arbeitsraum in absoluten Koordinaten sowie determinis- tisch vorgeplante Bewegungen durch den Generator erzeugt und müssen nicht mehr gelernt werden. Im Fall kraftgeregelter Spiralsuchbewegungen wird das Problem teil- weise linearisiert, da die deterministische Spiralform nicht mitgelernt werden muss, sondern lediglich die Abweichungen der realen von der geplanten Trajektorie. Durch den Einsatz starker Priore kann der Bedarf an Trainingsdaten um eine Größenord- nung deutlich reduziert werden. Dieser Effekt ist bei langen Trajektorien oder Trajek- torien mit starkem Determinismus besonders markant. Beim Training eines Baustein- repräsentanten für die kraftgeregelte Spiralsuche kann im Rahmen eines Ausfüh- rungsbeispiels die benötigte Menge an Trainingsdaten um den Faktor 20 reduziert werden. Der Einsatz eines differenzierbar implementierten analytischen Generators als starke Priore ist von erheblichem Vorteil.
- Darstellung der Parametervektoren: Die Parametervektoren xt jedes Baustein- repräsentanten i sind bausteinabhängig und sind das Ergebnis der Konkaten- ation der jeweiligen Parameter. Posenwertige Parameter können als Vektoren der Länge 7 dargestellt werden, wobei die ersten 3 Einträge die Position im kartesischen Raum und die letzten 4 Einträge die Orientierung als Quaternion darstellen können. Die Darstellung als Quaternion hat den Vorteil, dass sie ohne Singularitäten interpolierbar sind und die einzelnen Komponenten glatte Verläufe über die Zeit annehmen, was das Lernproblem deutlich vereinfacht. Kräfte und Momente können als Vektoren der Länge 6 dargestellt werden, die die Kräfte entlang der 3 kartesischen Raumrichtungen und die Momente um die 3 kartesischen Raumachsen designieren. Die Parametervektoren xt ent- halten sowohl optimierbare als auch konstante Parameter. Grundsätzlich kön- nen die xt der Bausteinrepräsentanten weniger oder andere Parameter als die korrespondierenden Programmbausteine enthalten, solange eine Bijektion zwischen den Parametervektoren existiert und das Verhalten bei gleicher Pa- rametrierung gleich ist. Dies ist z.B. bei „Spiralsuche (Relativ)“ der Fall: Der ARTM-Baustein akzeptiert für die Berechnung der Suchregion vier Posen, wel- che in einer Ebene liegen und die vier Ecken eines Parallelogramms relativ zur Startpose beschreiben. Für den Bausteinrepräsentanten wird diese Darstel- lung in zwei reelle Zahlen umgewandelt, welche die Ausdehnung des Paralle- logramms in x- und y-Richtung beschreiben. Diese Darstellung ist deutlich kompakter, aber mathematisch äquivalent. Lange xt erschweren das Lern- und Inferenzproblem deutlich, weshalb möglichst kompakte Darstellungen der Pa- rameter vorteilhaft sind.
Darstellung der Zustandsvektoren: In einer beispielhaften Implementierung be- steht st aus der TCP-Pose des letzten Datenpunkts der prädizierten Trajekto- rie, unter Verwendung der oben beschriebenen Konvention für Posen. Je nach Ausprägung des Verfahrens kann ^^ um Kräfte und Momente, die Gelenkwin- kelstellung des Roboters oder die Posen von manipulierten oder durch externe Sensorik erkannten Objekten in der Umgebung bestehen. - Darstellung von Trajektorien: Trajektorien werden in einer beispielhaften Im- plementierung als zweidimensionale Tensoren dargestellt, wobei die erste Di- mension variabler Länge die Zeitachse darstellt. Die zweite Dimension ist fes- ter Länge. In der Referenzimplementierung haben Trajektorien in der zweiten Dimension 14 Einträge, wobei die ersten 7 Einträge die Pose des TCP in Welt- koordinaten nach der o.g. Konvention beschreiben und die darauffolgenden 6 Einträge die Kräfte und Momente nach der o.g. Konvention. Der letzte Eintrag ist die Erfolgswahrscheinlichkeit PerrfoI ger Bewegung, mit PerfoIg ∈ [0, 1]. Fer- ner kann der Raum der Trajektorien, insbesondere im Rahmen der Ausfüh- rungsbeispiele, mit y bezeichnet werden und eine Trajektorie aus diesem Raum mit ^. Die aus der Ausführung des i-ten Bausteins eines Roboterpro- gramms resultierende Trajektorie kann mit ^^ bezeichnet werden und der n-te Vektor in der Trajektorie yi mit (yi)n. Training der lernbaren Repräsentanten als Systemmodelle für den in dem zugehöri- gen Baustein gekapselten Teilprozess: - Trainingsalgorithmus für differenzierbare Bausteinrepräsentanten: Durch die Realisierung differenzierbarer Bausteinrepräsentanten als neuronale Netze werden diese trainierbar. In der beispielhaften Referenzimplementierung ge- mäß eines Ausführungsbeispiels werden diese auf Tripel (xtrain, Strain, ytrain) trainiert xtrain. ist der Parametervektor für den Programmbaustein und enthält sowohl die konstanten als auch die optimierbaren Bausteinparameter. Ytrain ist eine Sequenz von Vektoren, welche jeweils die absolute Position und Ori- entierung des TCP relativ zum Basiskoordinatensystem des Roboters, Kräfte und Momente am TCP in alle kartesischen Raumrichtungen und den Sta- tuscode enthalten, welcher encodiert, ob der Baustein erfolgreich ausgeführt wurde. Strain ist der gemessene Systemzustand zu Beginn der Ausführung des Bausteins. Der Trajektoriengenerator bildet (Xtrain, Strain) auf die priore Trajek- torie ab. Das rekurrente neuronale Netz bildet (Xtrain, ^^) auf Yres ab. Die aus Addition von Yres und ^^ esultierende erwartete posteriore Trajektorie Ypred. Die Prädiktion der Positions-, Orientierungs-, Kraft- und Momentenkomponen- ten wird als gemeinsames Lernproblem betrachtet und mittels einer speziellen Loss-Funktion ein gemeinsamer Loss-Wert berechnet. Dieser Regressions- loss ist die gewichtete Summe des mittleren quadratischen Fehlers der Positi- ons-, Kraft- und Momentenkomponenten sowie dem Winkelunterschied der in Quaternionen encodierten Orientierungskomponente. Die Prädiktion des Sta- tuscodes wird als binäres Klassifikationsproblem betrachtet und mittels der bi- nären Kreuzentropie (Binary Crossentropy) bewertet. Regressions- und Klas- sifikationsloss werden durch gewichtete Addition kombiniert und die Gewichte des neuronalen Netzes unter Einsatz eines gradientenbasierten Optimierungs- algorithmus gelernt. Die gewählte Repräsentation von Trajektorien sowie die Regressionslossfunktion für Trajektorien sind besonders vorteilhaft. - Implementierung: Für die Implementierung der Bausteinrepräsentanten kann in einer beispielhaften Referenzimplementierung gemäß einem Ausführungs- beispiel für jeden unterstützten Bausteintyp ein differenzierbarer Generator im- plementiert werden. Da sich die Repräsentanten unterschiedlicher Bausteinty- pen strukturell lediglich hinsichtlich der Länge des Parametervektors ^^ unter- scheiden, können Bausteinrepräsentanten generisch aus dem dazugehörigen Generator und einem untrainierten neuronalen Netz konstruiert werden. In der Referenzimplementierung wird für das Training der neuronalen Netze der Adam-Optimierungsalgorithmus verwendet (vgl. D. P. Kingma und J. Ba, „Adam: A Method for Stochastic Optimization“, ArXiv14126980 Cs, Dez.2014, Zugegriffen: Aug. 12, 2019. [Online]. Verfügbar unter: http://ar- xiv.org/abs/1412.6980; Algorithmus 1, Seite 2). Vor jedem Trainingsschritt werden die Einträge von Xtrain, Strainund Strain auf die Domäne [-1, 1] skaliert. Eine Ausnahme bildet der PerfoIg-Eintrag von Xtrain, da die Binary Crossen- tropy-Loss-Funktion Logits erwartet. Für das Training der Bausteinrepräsen- tanten und spätere Parameterinferenz werden sowohl die Label- als auch die prädizierten Trajektorien auf eine feste Länge aufgefüllt, da die rekurrenten Komponenten der Netzarchitektur Sequenzen fester Länge erwarten. Um die ursprüngliche Trajektorie wieder herstellen zu können, wird ein boolesches Flag Ppadding in der letzten Dimension der Trajektorientensoren hinzugefügt, welches angibt, ob der Datenpunkt zu der Padding-Sequenz gehört oder nicht. Um das Padding zu lernen, wird der Trainingsalgorithmus analog zur Prädik- tion von perfoig um ein weiteres Klassifikationsproblem erweitert.
Inferenzphase:
Kombination der gelernten Repräsentanten zu Gesamtsystemmodellen für jede zu- sammenhängende Sequenz kritischer Bausteine:
- Algorithmus: Da Programmbausteine sequentiell ausgeführt werden und die Ausführung vorangegangener Bausteine die Ausführungen nachfolgernder Bausteine beeinflusst, werden aufeinanderfolgende trainierte Bausteinreprä- sentanten zu einem gemeinsamen Berechnungsgraphen kombiniert (vgl. Fig. 9). Über den Zustandsvektors fließen Kontextinformationen wie die aktu- elle Position und Orientierung des TCP von einem Baustein zum nächsten. Die Parametervektoren xt für jeden Baustein i werden als Blattknoten in den Be- rechnungsgraphen eingespeist. Die resultierende erwartete posteriore Ge- samttrajektorie des Teilprogramms ist die Konkatenation der erwarteten poste- rioren Teiltrajektorien der konstituierenden Bausteinrepräsentanten. Jeder Verarbeitungsschritt innerhalb eines Bausteinrepräsentanten ist dergestalt, dass die Ausgabe nach der Eingabe differenzierbar ist, woraus die Ableitbar- keit des gesamten Bausteinrepräsentanten nach den Eingabeparametern folgt. Die Ende-zu-Ende-Differenzierbarkeit (Ableitbarkeit der ausgegebenen Trajektorien nach den Eingabeparametern) der Bausteinrepräsentanten sowie die Zustandsvektoren s* gewährleisten die Ende-zu-Ende-Differenzierbarkeit der Gesamttrajektorie nach den Parametervektoren. Diese differenzierbare Repräsentation komplexer Roboterprogramme stellt eine signifikante Neue- rung gegenüber dem Stand der Technik dar.
Implementierung: Konkret wird eine Python-Klassenhierarchie instantiiert, welche die Programmstruktur abbildet und deren Blätter die in Schritt 3 trai- nierten differenzierbaren Bausteinrepräsentanten enthalten. Das Wurzelobjekt (die Programmabstraktion) hält hierbei eine geordnete Liste aller Repräsen- tanten. Der differenzierbare Berechnungsgraph wird bei der sukzessiven Aus- wertung der Bausteinrepräsentanten durch das Autograd-Framework von Py- Torch dynamisch erzeugt (vgl. A. Paszke u. a., „Automatic differentiation in PyTorch“, Okt. 2017, Zugegriffen: Aug. 12, 2019. [Online] Verfügbar unter: https://openreview.net/forum?id=BJJsrmfCZ). Die Berechnung der Ge- samttrajektorie wird hierdurch auf die Auswertung des Berechnungsgraphen reduziert. Die Zustandsvektoren st werden unter ausschließlicher Verwendung differenzierbarer Operationen aus den prädizierten Teiltrajektorien der vorher- gehenden Bausteine (I -L) berechnet. In der Referenzimplementierung kor- respondiert die Berechnung der Entnahme der letzten Pose aus Y i-1
Inferenz optimaler Parameter:
-
-
- Trajektorientensors Y. LFehler berechnet die durchschnittliche Wahrscheinlich- keit, dass die Ausführung des Roboterprogramms fehlschlägt, über alle Punkte der Trajektorie.
- Algorithmus: Die Optimierung der Programmparameter erfolgt über eine Vari- ante von Neural Network Iterative Inversion (NNII) bzw. Gradientenabstieg im Eingaberaum(vgl. D. A. Hoskins, J. N. Hwang, und J. Vagners, „Iterative Inver- sion of neural networks and its application to adaptive control“, IEEE Trans. Neural Netw., Bd. 3, Nr. 2, S. 292-301 , März 1992, doi: 10.1109/72.125870): Zunächst werden die Parametervektoren xt im Berechnungsgraphen mit einer initialen Parametrierung und der Startzustand s0 mit dem aktuellen Zustand der Roboterzelle initialisiert. In jedem Schritt des iterativen Optimierungsver- fahrens wird die erwartete Gesamttrajektorie durch Auswertung des Berech- nungsgraphen prädiziert und die Zielfunktion ausgewertet. Mit einem gradien- tenbasierten Optimierungsverfahren werden die Parametervektoren inkremen- teil in Richtung des Gradienten der Loss-Funktion angepasst, nämlich gemäß folgender Formel:
Die Formel betrifft eine Neural Network Iterative Inversion (NNII) (Gradienten- abstieg im Eingaberaum), wobei l die Lernrate bezeichnet. Die Gradienten konstant markierter Parameter werden in jedem Optimierungsschritt ausmas- kiert. Nach einer endlichen Anzahl an Iterationen (100 < N < 1000) konvergie- ren die Parameter in einem lokalen Minimum. Wie alle auf Gradientenabstieg basierenden Optimierungsverfahren ist NNII für konvexe Loss-Funktion asymptotisch optimal, d.h. konvergiert in beliebig vielen Iterationsschritten und bei beliebig kleiner Lernrate auf ein globales Minimum. In der realen Anwen- dung hängt die globale Konvergenz von NNII aufgrund lokaler Minima der Loss-Funktion von der initialen Parametrierung ab. In der Praxis kann Konver- genz durch Einsatz von Monte-Carlo-Methoden (Meta-Optimierung durch wie- derholte Optimierung ausgehend von zufällig gesampelten initialen Paramet- rierungen) oder ähnlichen Black-Box-Optimierungsverfahren unter Aufwand zusätzlicher Rechenzeit garantiert werden. Zudem liegt die initiale, d.h. vom Roboterprogrammierer ursprünglich vorgegebene, Parametrierung in vielen Fällen bereits in einer lokal konvexen Region der Zielfunktion um das globale Optimum. Der Einsatz von NNII (Gradientenabstieg im Eingaberaum) für die Inferenz optimaler Roboterprogrammparameter stellt eine signifikante Verbes- serung dar.
- Implementierung. Zum Lösen des Minimierungsproblems wird die PyTorch-lm- plementierung des Adam-Optimierungsalgorithmus verwendet. Dieser wird mit den als optimierbar (nicht konstant) deklarierten Parametern der Bausteinre- präsentanten des aktuell betrachteten Teilprogramms initialisiert. Hierzu sei auf folgenden Pseudocode zum Neural Network Iterative Inversion (NNII) Ver- fahren verweisen:
Die Schrittweite (lr bzw. l) ist ein global einstellbarer Hyperparameter des Optimierungsalgorithmus, deren Wahl von der Anwendungsdomäne, Ein- schränkungen bei der Rechenzeit für die Optimierung und den gewünschten Konvergenzeigenschaften des Optimierungsverfahrens abhängt. Für große Werte von l konvergiert Adam schneller, kann jedoch bei ungünstigen Kombi- nationen von Zielfunktionen oszillieren. Für kleine Werte von l konvergiert Adam langsamer, oszilliert jedoch deutlich weniger und terminiert näher am globalen Optimum. Je nach Ausprägung des Verfahrens kann der Adam-Opti- mierungsalgorithmus um Mechanismen wie Weight Decay oder Learning Rate Scheduling ergänzt werden, um Konvergenz und Laufzeit dynamisch auszu- balancieren. Für die Berechnung der Gradienten (backpropagate) wird die Autograd-Bibliothek von PyTorch verwendet. Abgesehen von den optimierba- ren Eingabeparametern der Bausteine (optimizable_params) bleiben alle anderen Parameter (konstante Bausteinparameter, aber auch die Gewichte der neuronalen Netze innerhalb der Bausteinrepräsentanten) konstant.
Fig. 10 zeigt eine rekurrente Netzarchitektur für ein Ausführungsbeispiel der Erfin- dung. Die Länge s des Zustandsvektors und die Länge x des Parametervektors sind einstellbar bzw. bausteinabhängig. Die Sequenzlänge ist hier auf 500 festgelegt. Die Batch-Dimension wurde zur Vereinfachung weggelassen.
Das Netz bildet Eingaben (links) auf Ausgaben (rechts) ab.
Eingaben:
- Die priore Trajektorie (Ausgabe des Trajektoriengenerators), ein Tensor der Dimension (500, 13) (eine 500x13 Matrix, also 500 Vektoren der Länge 13)
- Der aktuelle Zustand, ein Vektor der Länge p, je nachdem wie man den Zu- stand als Vektor kodiert. In einer beispielhaften Implementierung ist die Länge des Zustandsvektors bausteinabhängig, manche Bausteine können noch Zu- satzinformationen wie die aktuelle Greiferöffnung etc. benötigen, die andere Bausteine nicht benötigen.
- Der Vektor der Eingabeparameter mit Länge x (die Länge ist bausteinabhän- gig, da die Bausteine unterschiedliche Parameter haben)
Ausgaben:
Die residuale Trajektorie, ein Tensor der Dimension (500, 13). In Fig. 8 ist das Dieses Residuum ergibt addiert auf die priore Trajektorie die posteriore Trajektorie - Ppadding: Ein Tensor der Dimension (500, 1), der für jeden Zeitschritt der Trajektorie angibt, ob er zum Padding gehört oder nicht (enthält Werte zwi- schen 0 und 1). - PerfoIg: Ein Tensor der Dimension (500, 1), der für jeden Zeitschritt der Trajek- torie die Erfolgswahrscheinlichkeit des Bausteins zu diesem Zeitpunkt angibt (enthält Werte zwischen 0 und 1). Von links nach rechts ergibt sich folgende Funktionsweise: - Zunächst werden Zustand und Eingabevektor durch Wiederholung in Tenso- ren der Dimensionen (500, p) bzw. (500, x) umgewandelt. - Der dadurch entstehende Tensor wird durch eine vollverbundene Schicht (Fully Connected Network, FCN) auf einen Tensor der Dimension (500, 256) abgebildet. - Es folgen 4 Gated Recurrent Units (GRU), rekurrente Netzschichten, die je- weils Ausgabetensoren der Dimension (500, 256) produzieren. Für eine theo- retische Betrachtung von GRUs, siehe K. Cho u. a., „Learning Phrase Re- presentations using RNN Encoder–Decoder for Statistical Machine Transla- tion“, in EMNLP, Doha, Qatar, Okt.2014, S.1724–1734, doi: 10.3115/v1/D14- 1179. Für eine praktische Implementierung, siehe die PyTorch-Implementie- rung von GRUs unter https://pytorch.org/docs/master/genera- ted/torch.nn.GRU.html. Die GRUs sind "residual" (dies hat nichts mit der resi- dualen Trajektorie , d.h. die Ausgaben eines GRUs sind nicht nur Eingaben für das darauffolgende GRU, sondern auch das übernächste. Diese ist in Fig.10 durch die dünnen Pfeile und die gestrichelten Tensoren angedeu- tet. - Die Ausgabe des letzten GRUs wird durch eine letzte vollverbundene Schicht in die residuale Trajektorie, Ppadding und PerfoIg umgewandelt. - Auf jeder Schicht folgt eine nachgelagerte Aktivierungsfunktion, die jedoch zur Vereinfachung in der Fig. 10 nicht dargestellt ist. Hier werden Scaled Expo- nential Linear Units verwendet (SELU). Für eine theoretische Betrachtung von SELU, siehe G. Klambauer, T. Unterthiner, A. Mayr, und S. Hochreiter, „Self- Normalizing Neural Networks“, in NeurlPS, I. Guyon, U. V. Luxburg, S. Bengio, H. Wallach, R. Fergus, S. Vishwanathan, und R. Garnett, Hrsg. 2017, S. 971- 980. Für eine praktische Implementierung, siehe die PyTorch-lmplementierung von SELU unter https://pytorch.org/docs/master/genera- ted/torch. nn.SELU.html.
Performant wird das Training insbesondere dann, wenn man das Netz auf Batches von Trainingsdaten parallel auf einer Grafikarte (GPU) trainiert. Die Batch-Dimension wurde in der Fig. 10 zur Vereinfachung weggelassen. Gemäß einer Referenzimple- mentierung nach einem Ausführungsbeispiel können beispielsweise Batches der Größe 64 verwendet werden.
Hinsichtlich weiterer vorteilhafter Ausgestaltungen des erfindungsgemäßen Verfah- rens und des erfindungsgemäßen Systems wird zur Vermeidung von Wiederholun- gen auf den allgemeinen Teil der Beschreibung sowie auf die beigefügten Ansprüche verwiesen.
Schließlich sei ausdrücklich darauf hingewiesen, dass die voranstehend beschriebe- nen Ausführungsbeispiele des erfindungsgemäßen Verfahrens und des erfindungs- gemäßen Systems lediglich zur Erörterung der beanspruchten Lehre dienen, diese jedoch nicht auf die Ausführungsbeispiele einschränken.
Bezugszeichenliste Semi-symbolisches Roboterprogramm Kritisches Teilprogramm Kritischer Programmbaustein Kritischer Programmbaustein Semi-symbolisches Roboterprogramm Kritisches Teilprogramm Kritischer Programmbaustein Kritischer Programmbaustein Roboterzelle Programmiersystem Datenbank Lernsystem Ontologie System zur Spezifikation von Zielfunktionen Inferenzsystem

Claims

A n s p r ü c h e
1. Verfahren zur Bestimmung von optimierten Programmparametern für ein Ro- boterprogramm, wobei das Roboterprogramm zur Steuerung eines Roboters mit ei- nem Manipulator, vorzugsweise in einer Roboterzelle, dient, umfassend die Schritte:
Erzeugen des Roboterprogramms mittels eines bausteinbasierten grafischen Programmiersystems basierend auf Benutzereingaben, wobei das Roboterprogramm aus Programmbausteinen, die über Programmparameter parametrierbar sind, gebil- det wird, und wobei initiale Programmparameter für die Programmbausteine des Ro- boterprogramms erzeugt werden;
Bereitstellen einer Schnittstelle zum Auswählen eines oder mehrerer kritischer Programmbausteine, wobei optimierbare Programmparameter für die kritischen Pro- grammbausteine festlegbar sind;
Durchführen einer Explorationsphase zur Exploration eines Parameterraums in Bezug auf die optimierbaren Programmparameter, wobei das Roboterprogramm mehrfach ausgeführt wird, wobei eine Abtastung des Parameterraums für die kriti- schen Programmbausteine durchgeführt wird und Trajektorien des Roboters aufge- zeichnet werden, so dass für die kritischen Programmbausteine Trainingsdaten vor- liegen;
Durchführen einer Lernphase zum Erzeugen von Bausteinrepräsentanten für die kritischen Programmbausteine des Roboterprogramms basierend auf den in der Explorationsphase gesammelten Trainingsdaten, wobei ein Bausteinrepräsentant ein Systemmodell darstellt, das in Form einer differenzierbaren Funktion einen vorgege- benen Zustand des Roboters und vorgegebene Programmparameter auf eine prädi- zierte Trajektorie abbilden;
Durchführen einer Inferenzphase zur Bestimmung von optimierten Programm- parametern für die kritischen Programmbausteine des Roboterprogramms, wobei mit- tels eines gradientenbasierten Optimierungsverfahrens unter Einsatz der Bausteinre- präsentanten optimierbare Programmparameter der Bausteinrepräsentanten bezüg- lich einer vorgegebenen Zielfunktion iterativ optimiert werden.
2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass für die optimierba- ren Programmparameter Parameterdomänen festgelegt werden, wobei die optimier- baren Programmparameter über die Parameterdomänen optimiert werden.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Parameterdo- mänen für die optimierbaren Programmparameter vorgegeben und/oder vorgebbar bzw. einstellbar sind.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass in der Explorationsphase zur Abtastung des Parameterraums die optimierbaren Pro- grammparameter aus ihrer jeweiligen Parameterdomäne gesampelt werden, insbe- sondere gleichverteilt gesampelt oder adaptiv gesampelt werden.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass das Roboterprogramm in einem Format derart serialisiert abgespeichert wird, dass das Format eine Rekonstruktion und Parametrierung des Roboterprogramms bzw. dessen Programmbausteinen ermöglicht, vorzugsweise wobei das Format eine se- quentielle Ausführungsreihenfolge der Programmbausteine, Typen der Programm- bausteine, IDs der Programmbausteine, konstante Programmparameter und/oder op- timierbare Programmparameter umfasst.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass für eine Ausführung des Roboterprogramms eine abgetastete Trajektorie derart ge- speichert wird, dass jedem Datenpunkt der Trajektorie ein dazugehöriger Programm- baustein und eine Parametrierung des dazugehörigen Programmbausteins zum Zeit- punkt der jeweiligen Ausführung eindeutig zuordenbar ist.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass in der Explorationsphase das Roboterprogramm automatisiert ausgeführt wird, wobei mindestens 100 Ausführungen, vorzugweise mindestens 1000 Ausführungen, des Roboterprogramms zur Gewinnung der Trainingsdaten durchgeführt werden.
8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass die in der Explorationsphase gesammelten Trainingsdaten zu jeder Ausführung des Roboterprogramms eine Parametrierung, insbesondere konstante und/oder optimier- bare Programmparameter, der kritischen Programmbausteine und eine jeweils abge- tastete Trajektorie der kritischen Programmbausteine umfassen.
9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass die in der Explorationsphase gesammelten Trainingsdaten zu jedem ausgeführten Programmbaustein eine ID und/oder ein Statuscode umfassen.
10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass in der Lernphase für die kritischen Programmbausteine zunächst lernbare Baustein- repräsentanten erzeugt werden, wobei die lernbaren Bausteinrepräsentanten mit den Trainingsdaten der Explorationsphase trainiert werden, um dann als Bausteinreprä- sentanten Systemmodelle für in den dazugehörigen kritischen Programmbausteinen gekapselten Teilprozesse darzustellen.
11. Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass die Bausteinrepräsentanten ein rekurrentes neuronales Netz umfassen.
12. Verfahren nach Anspruch 11 , dadurch gekennzeichnet, dass zur Erzeugung der Bausteinrepräsentanten dem rekurrenten neuronalen Netz ein analytischer Trajektoriengenerator vorgeschaltet wird, wobei der analytische Trajektoriengenera- tor dazu ausgebildet ist, eine priore Trajektorie zu erzeugen.
13. Verfahren nach einem der Ansprüche 1 bis 12, dadurch gekennzeichnet, dass die Zielfunktion derart festgelegt wird, dass die Zielfunktion eine Trajektorie auf eine rationale Zahl abbildet und dass die Zielfunktion nach der Trajektorie differenzierbar ist.
14. Verfahren nach einem der Ansprüche 1 bis 13, dadurch gekennzeichnet, dass die Zielfunktion eine vordefinierte Funktion, eine parametrische Funktion und/oder ein neuronales Netz umfasst.
15. Verfahren nach einem der Ansprüche 1 bis 14, dadurch gekennzeichnet, dass die Zielfunktion eine auf Kraftmessung basierte Funktion umfasst.
16. Verfahren nach einem der Ansprüche 1 bis 15, dadurch gekennzeichnet, dass mit der Schnittstelle eine kritische Teilsequenz des Roboterprogramms auswählbar ist, wobei die kritische Teilsequenz mehrere kritischen Programmbausteine umfasst, wobei die Bausteinrepräsentanten der mehreren kritischen Programmbausteine zu einem differenzierbaren Gesamtsystemmodell kombiniert werden, das die Pro- grammparameter der kritischen Teilsequenz auf eine kombinierte Trajektorie abbil- det, so dass für eine zusammenhängende Teilsequenz von kritischen Programmbau- steinen die optimierbaren Programmparameter bezüglich der Zielfunktion optimiert werden.
17. System zur Bestimmung von optimierten Programmparametern für ein Robo- terprogramm, insbesondere zur Durchführung eines Verfahrens nach einem der An- sprüche 1 bis 16, wobei das Roboterprogramm zur Steuerung eines Roboters mit einem Manipulator, vorzugsweise in einer Roboterzelle, dient, umfassend: ein bausteinbasiertes grafisches Programmiersystem zum Erzeugen eines Ro- boterprogramms basierend auf Benutzereingaben, wobei das Roboterprogramm aus Programmbausteinen, die über Programmparameter parametrierbar sind, gebildet wird, und wobei initiale Programmparameter für die Programmbausteine des Robo- terprogramms erzeugbar sind; eine Schnittstelle zum Auswählen eines oder mehrerer kritischer Programm- bausteine, wobei optimierbare Programmparameter für die kritischen Programmbau- steine festlegbar sind; ein Explorationsmodul zur Exploration eines Parameterraums in Bezug auf die optimierbaren Programmparameter, wobei das Roboterprogramm mehrfach ausge- führt wird, wobei eine Abtastung des Parameterraums für die kritischen Programm- bausteine durchgeführt wird und Trajektorien des Roboters aufgezeichnet werden, so dass für die kritischen Programmbausteine Trainingsdaten vorliegen; ein Lernmodul zum Erzeugen von Bausteinrepräsentanten für die kritischen Programmbausteine des Roboterprogramms basierend auf den in der Explorations- phase gesammelten Trainingsdaten, wobei ein Bausteinrepräsentant ein Systemmo- dell darstellt, das in Form einer differenzierbaren Funktion einen vorgegebenen Zu- stand des Roboters und vorgegebene Programmparameter auf eine prädizierte Trajektorie abbilden; ein Inferenzmodul zur Bestimmung von optimierten Programmparametern für die kritischen Programmbausteine des Roboterprogramms, wobei mittels einem gra- dientenbasierten Optimierungsverfahren unter Einsatz der Bausteinrepräsentanten optimierbare Programmparameter der Bausteinrepräsentanten bezüglich einer vor- gegebenen Zielfunktion iterativ optimiert werden.
EP21739967.4A 2020-07-28 2021-06-04 Verfahren und system zur bestimmung von optimierten programmparametern für ein roboterprogramm Pending EP3965999A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102020209511.6A DE102020209511B3 (de) 2020-07-28 2020-07-28 Verfahren und System zur Bestimmung von optimierten Programmparametern für ein Roboterprogramm
PCT/DE2021/200076 WO2022022784A1 (de) 2020-07-28 2021-06-04 Verfahren und system zur bestimmung von optimierten programmparametern für ein roboterprogramm

Publications (1)

Publication Number Publication Date
EP3965999A1 true EP3965999A1 (de) 2022-03-16

Family

ID=76859381

Family Applications (1)

Application Number Title Priority Date Filing Date
EP21739967.4A Pending EP3965999A1 (de) 2020-07-28 2021-06-04 Verfahren und system zur bestimmung von optimierten programmparametern für ein roboterprogramm

Country Status (4)

Country Link
US (1) US20230311309A1 (de)
EP (1) EP3965999A1 (de)
DE (1) DE102020209511B3 (de)
WO (1) WO2022022784A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022065759A (ja) * 2020-10-16 2022-04-28 セイコーエプソン株式会社 ロボットのパラメーターセットを調整する方法、プログラム、および情報処理装置
DE102022107392A1 (de) 2022-03-29 2023-10-05 Gerhard Schubert Gesellschaft mit beschränkter Haftung Verfahren zum Beschleunigen einer Handhabungs-Maschine
CN118656984A (zh) * 2024-08-15 2024-09-17 河北工业大学 一种工业机器人动力学参数集的确定方法

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102010012598A1 (de) 2010-02-26 2011-09-01 Kuka Laboratories Gmbh Prozessmodulbibliothek und Programmierumgebung zur Programmierung eines Manipulatorprozesses
US20150127154A1 (en) 2011-06-02 2015-05-07 Brain Corporation Reduced degree of freedom robotic controller apparatus and methods
WO2015078992A1 (en) 2013-11-27 2015-06-04 Engino.Net Ltd. System and method for teaching programming of devices
DE102015204641B4 (de) 2014-06-03 2021-03-25 ArtiMinds Robotics GmbH Verfahren und System zur Programmierung eines Roboters
KR102645817B1 (ko) 2016-12-06 2024-03-08 한화로보틱스 주식회사 로봇의 비헤이비어 관리 방법 및 장치
JP6933167B2 (ja) * 2018-03-14 2021-09-08 オムロン株式会社 ロボットの制御装置
US20200156241A1 (en) 2018-11-21 2020-05-21 Ford Global Technologies, Llc Automation safety and performance robustness through uncertainty driven learning and control
DE102019207017B3 (de) 2019-05-15 2020-10-29 Festo Se & Co. Kg Eingabeeinrichtung, Verfahren zur Bereitstellung von Bewegungsbefehlen an einen Aktor und Aktorsystem

Also Published As

Publication number Publication date
DE102020209511B3 (de) 2021-08-19
WO2022022784A1 (de) 2022-02-03
US20230311309A1 (en) 2023-10-05

Similar Documents

Publication Publication Date Title
DE102020209511B3 (de) Verfahren und System zur Bestimmung von optimierten Programmparametern für ein Roboterprogramm
EP3013537B1 (de) Verfahren und system zur programmierung eines roboters
DE112010000775B4 (de) Industrierobotersystem
DE102012218297B4 (de) Verfahren zur dynamischen Optimierung einer Robotersteuerschnittstelle
DE69635162T2 (de) Hybride steuerungsarchitektur mit mehreren agenten
DE102015010124B4 (de) Roboterprogramm-Erzeugungsvorrichtung, die Roboterprogramm zum Reduzieren von Stössen der Gelenke des Roboters erzeugt
DE102015106227B3 (de) Steuern und/oder Regeln von Motoren eines Roboters
DE102019205651B3 (de) Verfahren und System zum Ausführen von Roboterapplikationen
EP3623116A1 (de) Verfahren und vorrichtung zur kollisionsfreien bewegungsplanung eines manipulators
DE102020120116B4 (de) Verfahren zur impedanzbasierten Multi-Tasking Tracking-Regelung, impedanzbasierter Multi-Tasking Tracking-Regler und kraft- und/oder drehmomentgeregelter Roboter
DE102019006725A1 (de) Steuereinrichtung und Steuersystem
DE102016000754A1 (de) Verfahren und System zur Bahnplanung eines redundanten Roboters
WO2019029870A1 (de) Handhabungseinrichtung mit einem roboter sowie verfahren und computerprogramm
DE102020212658A1 (de) Vorrichtung und Verfahren zum Steuern einer Robotervorrichtung
DE102020201398B3 (de) Betreiben einer Applikation eines Robotersystems
DE102021201918A1 (de) Vorrichtung und Verfahren zum Steuern ein oder mehrerer Roboter
EP3328595A2 (de) Verfahren und system zum steuern eines roboters
EP3356894B1 (de) Verfahren zur automatischen konfiguration eines externen steuerungssystems zur steuerung und/oder regelung eines robotersystems
DE102017007909A1 (de) Produktionssteuerung, ausgestattet mit einer Funktion zur Identifizierung der Ursache nach einem Betriebsstop einer Produktionseinrichtung, die Fertigungseinrichtungen umfasst
DE102020200165B4 (de) Robotersteuereinrichtung und Verfahren zum Steuern eines Roboters
EP4121825A1 (de) Computerimplementiertes verfahren zum erstellen von steuerungsdatensätzen, cad-cam-system und fertigungsanlage
DE102020210823A1 (de) Maschinen-Steueranordnung
DE102020127532B3 (de) Regelungsverfahren zum Regeln des Drehmoments und/oder der Position mindestens eines elastizitätsbehafteten Gelenks einer Handhabungsvorrichtung, Drehmomentregler, Positionsregler und Verwendung des Verfahrens zur Regelung der Position und/oder des Drehmoments mindestens eines elastizitätsbehafteten Gelenks einer Handhabungsvorrichtung
DE102020103854B4 (de) Maschinelles Lernen einer erfolgreich abgeschlossenen Roboteranwendung
EP3884347B1 (de) Kollisionsprüfung auf basis höherwertiger geometrie

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20211025

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20240208