-
Die vorliegende Erfindung betrifft ein Verfahren und System zur, insbesondere webbasierten, Kommunikation zwischen wenigstens einem Bediengerät und wenigstens einer Robotersteuerung, insbesondere zur Visualisierung einer Roboterapplikation sowie ein Computerprogrammprodukt zur Durchführung des Verfahrens.
-
Aufgabe der vorliegenden Erfindung ist es, die Kommunikation zwischen Bediengeräten und Robotersteuerungen zu verbessern.
-
Diese Aufgabe wird durch ein Verfahren mit den Merkmalen des Anspruchs 1 gelöst. Ansprüche 9, 10 stellen ein System bzw. Computerprogrammprodukt zur Durchführung eines hier beschriebenen Verfahrens unter Schutz. Die Unteransprüche betreffen vorteilhafte Weiterbildungen.
-
Nach einer Ausführung der vorliegenden Erfindung werden zur, in einer Ausführung webbasierten, Kommunikation zwischen einem oder mehreren Bediengerät(en) und einer oder mehreren Steuerung(en), die (jeweils) einen oder mehrere Roboter steuert bzw. hierzu vorgesehen, insbesondere eingerichtet ist/sind bzw. verwendet wird/werden („Robotersteuerung“), in einer Ausführung zur Visualisierung, insbesondere 3D-Visualisierung, einer oder mehrerer Applikation(en) dieses bzw. dieser Roboter („Roboterapplikation“), Daten von dem (jeweiligen) Bediengerät an die (jeweilige) Robotersteuerung und/oder von der (jeweiligen) Robotersteuerung an das (jeweilige) Bediengerät mittels eines HTTP-Protokolls übertragen.
-
Das bzw. eines oder mehrere der Bediengerät(e) ist/sind in einer Ausführung (jeweils) ein externes, tragbares und/oder universelles Bediengerät, insbesondere ein Tablet, Laptop oder Smartphone. Der bzw. einer oder mehrere der Roboter ist/sind in einer Ausführung (jeweils) ein mehr-, insbesondere wenigstens sechs-, in einer Ausführung wenigstens siebenachsiger Roboter.
-
In einer Ausführung werden Daten von dem Bediengerät an die Robotersteuerung und/oder von der Robotersteuerung an das Bediengerät mittels eines HTTP/1.1 Protokolls, insbesondere mittels REST („Representational State Transfer“) übertragen.
-
Hiermit geht in einer Ausführung eine vorhergehende und/oder dokumentierbare Schnittstelle einher. In einer Ausführung basiert ein REST-Aufruf auf einer HTTP-Anfrage, welche in einer Ausführung einen HTTP-Header und einen optionalen HTTP-Body aufweist. Im Header sind in einer Ausführung diverse Meta-Informationen enthalten, insbesondere welche HTTP-Methode verwendet werden soll, welcher Art von Client den Aufruf tätigt oder dergleichen. Im HTTP-Body stehen in einer Ausführung die eigentlichen bzw. inhaltlichen Daten. Als Antwort auf diese Anfrage kommt in einer Ausführung ein HTTP-Response, in einer Ausführung ebenfalls mit einem HTTP-Header und/oder HTTP-Body.
-
Ein Nachteil von REST und somit auch von HTTP 1.1 in diesem Kontext ist, dass REST immer einen Request benötigt, um dem Client eine Antwort - in Form einer Response - zuzuschicken. Um aber das Bediengerät zu befähigen, Updates zu erhalten, ohne dass der Client aktiv in einem bestimmten Intervall nachfragen muss („long term polling“), wird REST in einer Ausführung in Verbindung mit WebSockets verwendet.
-
Entsprechend werden in einer Ausführung Daten von der bzw. einer oder mehrerer der Robotersteuerung(en jeweils) mittels eines WebSocket-Protokolls an das (jeweilige) Bediengerät übertragen.
-
Hierzu wird in einer Ausführung eine TCP-Verbindung genutzt und/oder, anders als bei HTTP/1.1, keine zusätzlichen Meta-Informationen (Header) versendet. Die Verbindungsart kann als direkt tituliert werden und verfolgt vorzugsweise kein bestimmtes Schema.
-
Werden beide Technologien bzw. Protokolle HTTP/1.1 und WebSocket in einer Ausführung in Kombination verwendet, eliminieren sich die jeweiligen Nachteile. In einer Ausführung werden client-seitige Anfragen mit REST und/oder server-seitige Aktualisierungen („Push Notifications“) mittels WebSockets realisiert.
-
Nachteilig müssen dabei jedoch für eine webbasierte Roboter-Interaktions-Möglichkeit zwei Technologien benutzt, gepflegt und implementiert werden.
-
Daher werden in einer Ausführung die Daten von dem (jeweiligen) Bediengerät an die (jeweilige) Robotersteuerung und/oder von der (jeweiligen) Robotersteuerung an das (jeweilige) Bediengerät mittels eines HTTP/2-Protokolls oder eines höheren bzw. jüngeren HTTP-Protokolls übertragen, insbesondere HTTP/2 gemäß RFC 7540 und/oder RFC 7541 oder höher bzw. jünger.
-
In einer Ausführung muss, insbesondere gegenüber HTTP/1.1, vorteilhaft eine geringere Datenmenge übertragen werden. In einer Ausführung werden die Inhalte binär und/oder nicht im Text-Format übertragen, was eine Datenkompression ermöglichen kann. In einer Ausführung können, insbesondere durch eine TCP-Verbindung, mehrere Anfragen („Multiplexing“) übertragen werden, was in einer Ausführung einen Geschwindigkeitsvorteil bringt. In einer Ausführung werden die Daten in Echtzeit übertragen.
-
gRPC, von Google entwickelt, eignet sich hervorragend als Ersatz für die REST Kommunikation. Durch den Einsatz von gRPC erhält der Entwickler in einer Ausführung eine direkte Datenstruktur-Sicherheit („protobuf“) und/oder die Möglichkeit programmiersprachenunabhängig Client- sowie Server-Code zu schreiben.
-
Entsprechend werden in einer Ausführung die Daten mittels eines gRPC-Protokolls übertragen.
-
Insbesondere, um auch bei einer fehlenden bzw. nicht dem gRPC-Protokoll entsprechenden Fetch-API gRPC-basierte Aufrufe von einem Webbrowser zu einer Robotersteuerung direkt zu vollziehen, wird in einer Ausführung die Verbindung zwischen Webbrowser und gRPC-Service durch wenigstens einen Proxy geschleust, der das Protokoll in einer Ausführung wiederum für den Browser kompatibel macht.
-
Allgemein werden die Daten in einer Ausführung über wenigstens einen Proxy übertragen, wodurch in einer Ausführung das vorstehend genannte Problem gelöst werden kann.
-
In einer Ausführung holt der (jeweilige) Client, auf dem wenigstens eine Anwendung läuft, aktiv Informationen von der (jeweiligen) Robotersteuerung, insbesondere welcher Roboter verfügbar ist, welche(r) Frame(s) in der Applikation verwendet wird/werden oder dergleichen. Zusätzlich oder alternativ benachrichtigt in einer Ausführung die (jeweilige) Robotersteuerung den (jeweiligen) Clienten über Statusänderungen, insbesondere Sicherheitsverletzungen, Roboter-Positionen und/oder dynamische Frame-Bewegungen.
-
Allgemein können die Daten, die von dem (jeweiligen) Bediengerät an die (jeweilige) Robotersteuerung und/oder von der (jeweiligen) Robotersteuerung an das (jeweilige) Bediengerät übertragen werden, roboter- und/oder applikationsspezifische Daten sein und/oder von Roboterpositionen, (Roboter)Applikationen, Sicherheitsverletzungen und/oder verwendeten Frames abhängen, diese, in einer Ausführung deren, insbesondere zeitliche bzw. dynamische, Änderungen, insbesondere angeben.
-
Nach einer Ausführung der vorliegenden Erfindung ist ein System, insbesondere hard- und/oder software-, insbesondere programmtechnisch, zur Durchführung eines hier beschriebenen Verfahrens eingerichtet und/oder weist Mittel zum Übertragen von Daten von dem Bediengerät an die Robotersteuerung und/oder von der Robotersteuerung an das Bediengerät mittels eines HTTP Protokolls auf.
-
Ein Mittel im Sinne der vorliegenden Erfindung kann hard- und/oder softwaretechnisch ausgebildet sein, insbesondere eine, vorzugsweise mit einem Speicher- und/oder Bussystem daten- bzw. signalverbundene, insbesondere digitale, Verarbeitungs-, insbesondere Mikroprozessoreinheit (CPU), Graphikkarte (GPU) oder dergleichen, und/oder ein oder mehrere Programme oder Programmmodule aufweisen. Die Verarbeitungseinheit kann dazu ausgebildet sein, Befehle, die als ein in einem Speichersystem abgelegtes Programm implementiert sind, abzuarbeiten, Eingangssignale von einem Datenbus zu erfassen und/oder Ausgangssignale an einen Datenbus abzugeben. Ein Speichersystem kann ein oder mehrere, insbesondere verschiedene, Speichermedien, insbesondere optische, magnetische, Festkörper- und/oder andere nicht-flüchtige Medien aufweisen. Das Programm kann derart beschaffen sein, dass es die hier beschriebenen Verfahren verkörpert bzw. auszuführen imstande ist, sodass die Verarbeitungseinheit die Schritte solcher Verfahren ausführen kann und damit insbesondere eine Kommunikation zwischen dem bzw. den Bediengerät(en) und der bzw. den Robotersteuerung(en) durchführen kann. Ein Computerprogrammprodukt kann in einer Ausführung ein, insbesondere nicht-flüchtiges, Speichermedium zum Speichern eines Programms bzw. mit einem darauf gespeicherten Programm aufweisen, insbesondere sein, wobei ein Ausführen dieses Programms ein System bzw. eine Steuerung, insbesondere einen Computer, dazu veranlasst, ein hier beschriebenes Verfahren bzw. einen oder mehrere seiner Schritte auszuführen.
-
In einer Ausführung werden ein oder mehrere, insbesondere alle, Schritte des Verfahrens vollständig oder teilweise automatisiert durchgeführt, insbesondere durch das System bzw. sein(e) Mittel. In einer Ausführung weist das System den Roboter, das bzw. eines oder mehrere der Bediengerät(e) und/oder die bzw. eine oder mehrere der Robotersteuerung(en) auf.
-
Weitere Vorteile und Merkmale ergeben sich aus den Unteransprüchen und den Ausführungsbeispielen. Hierzu zeigt, teilweise schematisiert:
- 1: ein System bzw. Verfahren nach einer Ausführung der vorliegenden Erfindung; und
- 2: eine 3D-Visualisierung des Roboters 1.
-
1 zeigt ein System bzw. Verfahren nach einer Ausführung der vorliegenden Erfindung.
-
Eine Robotersteuerung 10 zum Steuern eines Roboters 1 weist mehrere Services 11...13 auf, insbesondere einen Applikations-Framework-Service („Application Framework Service“), einen Applikations-Kontroll-Service („Application Control Service“), einen Roboter-Service („Robot Service“), einen Szenengraphen-Service („Scenegraph Service“), einen Jogging-Service, einen Positions-Service und/oder einen Hardware-Service, die alle mit einem gRPC-Server 14 kommunizieren.
-
In einer Ausführung kommunizieren eine oder mehrere Nicht-Webbrowser-Anwendungen 3, insbesondere mittels HTTP/2-Protokoll, mit dem gRPC-Server 14.
-
Der gRPC-Server 14 kommuniziert mittels HTTP/2-Protokoll mit einem gRPC-Browser-Proxy 15, der seinerseits mittels HTTP/2-Protokoll mit einem gRPC-Web-Clienten 21 eines Bediengeräts 20 kommuniziert. Der gRPC-Web-Clienten 21 kommuniziert mit einer Benutzerschnittstelle („User Interface“ Ul) 22 des Bediengeräts 20.
-
2 zeigt eine 3D-Visualisierung des Roboters 1 mit Frames 100, TCPs 200 und einem Roboter-Interaktionspanel 300.
-
Obwohl in der vorhergehenden Beschreibung exemplarische Ausführungen erläutert wurden, sei darauf hingewiesen, dass eine Vielzahl von Abwandlungen möglich ist. Außerdem sei darauf hingewiesen, dass es sich bei den exemplarischen Ausführungen lediglich um Beispiele handelt, die den Schutzbereich, die Anwendungen und den Aufbau in keiner Weise einschränken sollen. Vielmehr wird dem Fachmann durch die vorausgehende Beschreibung ein Leitfaden für die Umsetzung von mindestens einer exemplarischen Ausführung gegeben, wobei diverse Änderungen, insbesondere in Hinblick auf die Funktion und Anordnung der beschriebenen Bestandteile, vorgenommen werden können, ohne den Schutzbereich zu verlassen, wie er sich aus den Ansprüchen und diesen äquivalenten Merkmalskombinationen ergibt.
