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 ( p _er foi _g ) 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/s ² , 0.05m/s ² ]. 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 f _B , die gegeben den Eingabeparametern x _B des Programmbausteins und dem Sys- temzustand p die erwartete Trajektorie Y _B 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 Y _B nach x _B . Dies erlaubt die Optimierung von x _B 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 x _t 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 x _t ent- halten sowohl optimierbare als auch konstante Parameter. Grundsätzlich kön- nen die x _t 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 x _t 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 s _t 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 P _errfoI ger Bewegung, mit P _erfoIg ∈ [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 y _i mit (y _i ) _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 (x _train , S _train , y _train ) trainiert x _train . ist der Parametervektor für den Programmbaustein und enthält sowohl die konstanten als auch die optimierbaren Bausteinparameter. Y _train 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. S _train ist der gemessene Systemzustand zu Beginn der Ausführung des Bausteins. Der Trajektoriengenerator bildet (X _train , S _train ) auf die priore Trajek- torie ab. Das rekurrente neuronale Netz bildet (X _train , ^ ^{^} ) auf Y _res ab. Die aus Addition von Y _res und ^ ^{^} esultierende erwartete posteriore Trajektorie Y _pred . 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 X _train , S _train und S _train auf die Domäne [-1, 1] skaliert. Eine Ausnahme bildet der P _erfoIg -Eintrag von X _train , 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 P _padding 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 p _er f _oig 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 x _t 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 s _t 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. L _Fehler 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 x _t im Berechnungsgraphen mit einer initialen Parametrierung und der Startzustand s ₀ 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 - P _padding : 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). - P _erfoIg : 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, P _padding und P _erfoIg 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