-
ERKLÄRUNG BEZÜGLICH STAATLICH UNTERSTÜTZTER FORSCHUNG ODER ENTWICKLUNG
-
Diese Erfindung erfolgte mit Unterstützung der Regierung unter der NASA Space Act Vereinbarung Nr. SAA-AT-07-003. Die Regierung der Vereinigten Staaten kann gewisse Rechte an dieser Erfindung haben.
-
TECHNISCHES GEBIET
-
Die vorliegende Erfindung betrifft Systeme und Verfahren zur Aufgabenplanung für einen automatisierten Roboter und insbesondere ein System mit einer Roboteraufgabensteuerungskomponente mit einer erweiterbaren Programmierumgebung, die für eine solche Aufgabenplanung verwendet werden kann und ein Verfahren, bei dem eine solche Roboteraufgabensteuerungskomponente verwendet wird.
-
HINTERGRUND
-
Roboter sind automatisierte Vorrichtungen, die Objekte unter Verwenden einer Reihe von mechanischen Gliedern handhaben können. Die Glieder sind mittels motor-/aktorbetriebener Robotergelenke miteinander verbunden. Jedes Gelenk stellt bei einem typischen Roboter eine unabhängige Steuervariable, d. h. einen Freiheitsgrad, dar. Greiforgane sind die speziellen Vorrichtungen, die sich am Ende eines Robotermanipulators befinden, der zum Durchführen einer anstehenden Aufgabe, wie etwa Greifen eines Werkzeugs oder Aufnehmen eines 3D-Bilds eines Objekts, verwendet wird. Daher kann eine präzise Steuerung eines Roboters nach der Ebene der Aufgabenspezifizierung organisiert sein: Objektebenensteuerung, d. h. die Fähigkeit, das Verhalten eines Objekts zu steuern, das mit einem einzelnen oder zusammenwirkenden Griff eines Roboters gehalten wird, Greiforgansteuerung und Gelenkebenensteuerung. Kollektiv wirken die verschiedenen Steuerungsebenen zusammen, um die erforderlichen Werte an Beweglichkeit, Geschicklichkeit und arbeitsaufgabenspezifischer Funktionalität des Roboters zu erreichen.
-
Roboter variieren bezüglich Komplexität von herkömmlichen Roboterarmen mit 3 Achsen oder 6 Achsen bis zu hoch komplexen humanoiden Robotern reichend, d. h. Robotern mit menschenähnlichem Aufbau oder Erscheinungsbild, sei es nun als kompletter Körper, Rumpf und/oder als Gliedmaße. Die strukturelle Komplexität eines humanoiden Roboters hängt zum großen Teil von der Art der durchgeführten Arbeitsaufgabe ab. Typischerweise weist jeder Roboter seine eigene dedizierte Programmierumgebung auf, wobei erfahrene Anwender die verschiedenen Aufgaben programmieren, die gemäß einer bestimmten Aufgabensequenz ausgeführt werden müssen. Der Programmiercode wird dann kompiliert, wobei Kommunikationsprotokolle jedes Mal neu geschrieben werden, wenn an den Roboter neue Peripheriegeräte und andere Hardware-Elemente angefügt werden. Dadurch kann es auf dem Gebiet gewisse Unwirtschaftlichkeiten bei der Aufgabenprogrammierung geben, insbesondere in größeren vernetzten Umgebungen, die Roboter unterschiedlicher Konstruktionen und/oder mit großen Unterschieden bei der relativen Komplexität nutzen.
-
In der
DE 10 2005 034 168 A1 ist ein Bedien-/Beobachtungsgerät beschrieben, das der Visualisierung von beobachteten Vorgängen dient und mittels eines Zugriffs auf ein angeschlossenes Steuergerät Bedienvorgänge ermöglicht. Das Bedien-/Beobachtungsgerät umfasst eine graphische Bedienoberfläche, Eingabemittel für einen Benutzer, eine Datenschnittstelle zur datentechnischen Verbindung des Bedien-/Beobachtungsgeräts mit einem Steuergerät, und eine prozessorgesteuerte Steuereinheit zum Ausführen von Softwareprogrammen. Dabei kann auf dem Steuergerät ein Interpreter-Programm ausgeführt werden, das auf Skripte mit Anzeigebausteinen und Programmstrukturen zugreifen kann. Die Programmstrukturen haben auf Betriebsdaten der Firmware des Steuergeräts Zugriff, wobei die Betriebsdaten in Anzeigedaten eines vorgebbaren Anzeigeformats umgewandelt werden und umgekehrt. Die Skripte werden abgearbeitet, wobei die Programmstrukturen das zugehörige Ergebnis in Form von Anzeigebausteinen gegebenenfalls mit Anzeigedaten im vorgegebenen Anzeigeformat zusammenstellen und das Ergebnis zur Verfügung stellen. Auf dem Bedien-/Beobachtungsgerät wird ein Anzeigeprogramm ausgeführt, um zumindest Anzeigebausteine im vorgebbaren Anzeigeformat darzustellen. In den Anzeigebausteinen sind Verweise auf zumindest ein Skript auf dem Steuergerät hinterlegt.
-
-
ZUSAMMENFASSUNG
-
Der Erfindung liegt die Aufgabe zugrunde, ein System sowie ein Verfahren der eingangs genannten Art anzugeben, mit denen die Aufgabenprogrammierung insbesondere in größeren vernetzten Umgebungen, in denen Roboter unterschiedlicher Konstruktion und/oder unterschiedlicher Komplexität eingesetzt werden, weiter optimiert wird und insbesondere wirtschaftlicher realisierbar ist.
-
Die Aufgabe wird erfindungsgemäß durch ein System mit den Merkmalen des Anspruchs 1 und ein Verfahren mit den Merkmalen des Anspruchs 6 gelöst. Bevorzugte Ausführungsformen des erfindungsgemäßen Systems sowie bevorzugte Ausgestaltungen des erfindungsgemäßen Verfahrens sind in den Unteransprüchen angegeben.
-
Hierin wird ein System offenbart, das eine Roboteraufgabensteuerungskomponente (kurz RTC, vom engl. Robot Task Commander) umfasst. Die RTC ist für die Entwicklung von verteilter Software auf Roboteranwendungsebene, d. h. Software, die nicht echtzeitkritisch ist, wie aus dem Gebiet bekannt ist, gedacht. Die RTC kann als Satz von Programmen umgesetzt werden, die auf einer oder mehreren Rechnervorrichtungen laufen, einschließlich einer integrierten Entwicklungsumgebung (kurz IDE, vom engl. Integrated Development Environment) mit einer grafischen Anwenderschnittstelle (kurz GUI, vom engl. Graphical User Interface) und einem oder mehreren Programmen, die ausgelegt sind, um als jeweilige Skript-Engines zu dienen. Die GUI dient als grafisches ”Frontend” für die RTC und ermöglicht einem erfahrenen oder unerfahrenen Anwender auf intuitive Weise die Interaktion mit den Skript-Engines. Die GUI ermöglicht es einem Anwender auch, Laufzeitdiagnoseinformationen einzusehen, neue Skripte zu verfassen, die in einem Speicher gespeichert werden können und auf die mittels eines grafischen Datei-Browsers zugegriffen werden kann, und solche gespeicherten Skripte als ”Codebibliothekblöcke” in neue Sequenzen zu ziehen und abzulegen. Die Aufgabensequenzen werden für eine hierarchische Wiederverwendung als ”Aufgabensequenzblöcke” in zusätzlichen Sequenzen analog in einem Speicher gespeichert.
-
Die GUI ermöglicht dem Anwender das Verwenden von Aufgabensequenzblöcken als ”Anwendungen” bei der Skript-Engine/den Skript-Engines. Die Skript-Engines dienen wiederum als rechnerisches ”Backend” der RTC. Subblöcke in einer Anwendung können spezifischen Skript-Engines zugeteilt werden, die dann diese bestimmten Blöcke in einer festgelegten Sequenzreihenfolge interpretieren und ausführen müssen. Daher sind die Skript-Engines innerhalb des Systems für das Übermitteln von Programmsequenzdaten zu anderen Skript-Engines sowie für das Kommunizieren von Diagnoserückmeldung zu der GUI zuständig. Eine Diagnoserückmeldung, wie sie hierin verwendet wird, kann zwei Formen annehmen: ein Textfenster in der GUI und eine ”Block-Markierung”, so dass bei Zuweisen einer Anwendung zu der Skript-Engine/den Skript-Engines die entsprechenden Blöcke in der GUI unterschiedliche Farben annehmen können, z. B. grün, um eine ordnungsgemäße Ausführung anzuzeigen, rot, um einen Fehler oder Defekt anzuzeigen, etc.
-
Die Verwendung der RTC wie hierin offenbart erleichtert eine automatisierte Roboteraufgabenplanung in einer vernetzten Umgebung, wobei ein oder mehrere Roboter durch mehrere Rechenvorrichtungen über eine Netzwerktransportebene (kurz NTL, vom engl. Network Transport Layer) gesteuert werden. Die RTC ist ausgelegt, um mehrere Netzwerkprotokolle, zum Beispiel das Robot Operating System (ROS), ZeroMQ, TCP/IP, UDP, etc., zum Implementieren der Netzwerkkommunikation zwischen verschiedenen Skript-Engines, der RTC-GUI, und einem oder mehreren Roboter/Peripheriegeräten zu unterstützen, ohne nur in einem bestimmten Protokoll vorhanden zu sein. Da Anwendungen aus Aufgabensequenzen von mehreren Blöcken bestehen können, die über ein großes Netzwerk auf mehrere Skript-Engines, die diese Protokolle verwenden, verteilt sein können, können Netzwerklatenzen vorhanden sein. Solche Latenzen sind aber innerhalb des Kontextes der beabsichtigten Anwendungsebenen-Softwareentwicklungsrolle der RTC durchaus hinnehmbar.
-
Die von der RTC verwendeten Skript-Engines können auf verschiedenen Rechnern im Netzwerk vorliegen. Jede Skript-Engine kann ”Auslösebefehle” zu anderen Skript-Engines senden, z. B. als Satz von koordinierten Zustandsautomaten, die parallel arbeiten. In einer solchen Umgebung ermöglicht es die GUI einem Anwender, auf einen Blick präzise zu erkennen, was in all den verschiedenen verteilten Skript-Engines passiert. Die verteilte Vorgehensweise ermöglicht auch ein Ausgleichen einer Rechnerbelastung über das Netzwerk hinweg, wenn bestimmte Bibliothekskript- oder Sequenzblöcke, die hierin nachstehend kollektiv als ”Codebibliotheksblöcke” bezeichnet werden, besonders intensiv sind, zum Beispiel im Fall von Sensor-/Bildfusions- oder Bildverarbeitungsalgorithmen.
-
Bei einer möglichen Vorgehensweise könnte eine bestimmte Skript-Engine einem entsprechenden Roboter an dem Netzwerk zugewiesen werden. Analog könnte jede Aufgabensequenz und jeder Codebibliotheksblock auf einer anderen Skript-Engine auf einem anderen Rechner laufengelassen werden. Im Allgemeinen kann das Verwenden jedes Blocks vor dem Verwenden durch den Anwender in der GUI festgelegt werden oder durch standardmäßige Terminierungsalgorithmen wie etwa ”Rundlaufverfahren” oder dergleichen automatisch der Skript-Engine/den Skript-Engines an dem Netzwerk zugewiesen werden, wie in dem Gebiet gut bekannt ist. Die bestimmten Auslösevorgänge, die die verschiedenen Blöcke verbinden, werden über die NTL gesendet, was es der RTC ermöglicht, selbst in einer stark verteilten Netzwerkumgebung ordnungsgemäß zu arbeiten. Die Aufgabensequenzen selbst müssen nicht linear sein. D. h. ein einzelner Auslösebefehl könnte das Ausführen von mehreren Codeblöcken zum gleichen Zeitpunkt auslösen, wodurch eine gleichzeitige oder parallele Verarbeitungspipeline gestartet wird usw.
-
Die hierin beschriebene RTC verwendet Skript-Blöcke, die eigens geschrieben sind, um ”Eingabe-”daten von einem Roboter und/oder Sensordaten, die über die NTL veröffentlicht werden, anzunehmen, wie aus dem Gebiet bekannt ist, sowie um ”Ausgangs-”daten zu der NTL selbst zu veröffentlichen. Beim Verfassen in der GUI der RTC müssen die Skripte ”abstrakt” geschrieben werden, d. h. agnostisch zu spezifischen Eingangs/Ausgangs(I/O)-Datenbindungen. Auf diese Weise kennt jeder einzelne Skript-Block nur die Art der Information, z. B. Gelenkpositionen, Gelenkgeschwindigkeiten, Bildkoordinaten, etc., und nicht die spezifische Quelle dieser Informationen. Es ist dem Anwender belassen, beim Verfassen von Codeblöcken in Aufgabensequenzen und/oder Anwendungen die Quellen und Senken dieser I/O-Daten in der VPL unter Verwenden einer intuitiven grafischen Schnittstelle zu ”binden”. Somit steht die Fähigkeit im Zentrum der vorliegenden Vorgehensweise, eine solche abstrakte Funktionalität in der Form von Bibliotheksskripten in unterschiedlichen Anwendungen zu verwenden und wiederzuverwenden, während möglicherweise an verschiedene Hartware-Geräte angebunden wird. Diese Konzepte werden nachstehend näher erläutert.
-
Wie für den Durchschnittsfachmann des Gebiets erkennbar ist, kann die hierin offenbarte RTC verschiedene Vorteile gegenüber bestehenden Befehls- und Steuerstrategien bieten. Solche Strategien können bei Schaffen neuer Roboteraufgabenanwendungen für das Zusammenspiel mit neu hinzugefügten peripheren Hardware-Geräten, wie etwa Sensoren, Manipulatoren und/oder externer Software in gleichbleibend einheitlicher Weise schlecht geeignet sein. Eine Online-Rückmeldung sowohl von Programmzustands- als auch Robotertelemetriedaten, die für Laufzeit-Selbstprüfung und Diagnose von laufenden Aufgaben brauchbar sein kann, fehlt möglicherweise gleichfalls im Stand der Technik. Für den Einsatz von externen Software-Paketen mittels Kommunikation über die NTL wird eine integrierte Unterstützung vorgesehen, und diese integrierte Unterstützung mehrerer Netzwerkprotokolle macht dies möglich. Zusammen können diese Merkmale ein schnelles Prototyping und Umsetzen von innovativen Roboterprogrammiertechniken ermöglichen, die für die nächste Generation von flexiblen allgemeinen Montagefertigungssystemen, Weltraumforschungssystemen und dergleichen geeignet sind. Als zusätzlicher Vorteil müssen durch Verwenden der RTC Kommunikationsprotokolle nicht immer neu geschrieben werden, wenn dem Netzwerk neue Hardware hinzugefügt wird.
-
In einer hierin offenbarten bestimmten Ausführungsform umfasst das System spezifisch einen Roboter mit einem zugeordneten Steuermodul. Das Steuermodul steuert als Reaktion auf eine angeordnete Aufgabe die Bewegung mindestens eines Gelenks des Roboters. Das System umfasst auch die vorstehend beschriebene RTC, die über die NTL in vernetzter Kommunikation mit dem Steuermodul steht. Die RTC umfasst einen Prozessor und einen Speicher mit einer zentralen Bibliothek, in der Codebibliotheksblöcke gespeichert werden können, wobei jeder Codebibliotheksblock mittels eines zugeordneten Texteditors unter Verwenden eines Rechnerprogrammiercodes für eine interpretierende Sprache konstruiert ist. Jeder Bibliothekscodeblock kann auch einen oder mehrere I/O-Anschlüsse haben, die hierin als bestimmte I/O-Elemente definiert sind, die über die NTL als Zeiger auf Eingabe- bzw. Ausgabedaten kommunizieren. Die RTC umfasst auch eine GUI, die mit dem Speicher in Verbindung steht. Die GUI bietet Zugriff sowohl auf die VPL-Umgebung als auch den Texteditor.
-
Die RTC führt als Reaktion auf Anwenderbefehle Anweisungen von dem Speicher aus, um dadurch die VPL zu öffnen und um es dem Anwender zu ermöglichen, Code für eine mittels des Roboters/der Roboter auszuführende Aufgabe auszuwählen oder zu entwickeln, einschließlich Auswählen und/oder Entwickeln eines oder mehrerer Codebibliotheksblöcke. Die ausgewählten/entwickelten Codeblöcke werden über die NTL zu den verschiedenen festgelegten Skript-Engines heruntergeladen, wo die Blöcke entsprechend dem Flusspfad/den Flusspfaden, die von den bestimmten Auslösebefehlen diktiert werden, ausgeführt werden. Nach dem Verarbeiten der Codebibliotheksblöcke mittels der Script-Engines steuert jedes Steuermodul anschließend die von der Aufgabe vorgegebene erforderliche Bewegung, wobei es mittels der Skript-Engines regelmäßig seinen Zustand zurück zu der steuernden RTC übermittelt. Hierin werden verschiedene Ausführungsformen des vorstehenden Systems näher dargelegt.
-
Die obigen Merkmale und Vorteile und weitere Merkmale und Vorteile der vorliegenden Erfindung werden aus der folgenden ausführlichen Beschreibung der besten Ausführungsarten der Erfindung, wenn diese in Verbindung mit den Begleitzeichnungen genommen wird, leicht deutlich.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
1 ist eine schematische Darstellung eines verteilten Robotersystems, das mehrere Roboter, individuelle Steuermodule und eine Roboteraufgabensteuerungskomponente (RTC), die wie hierin dargelegt ausgelegt ist, umfasst.
-
2 ist ein schematisches Flussdiagramm, das eine Programmentwicklung unter Verwenden der RTC des in 1 gezeigten Systems beschreibt.
-
3 ist ein schematisches Flussdiagramm, das eine Roboteraufgabenplanung unter Verwenden der RTC beschreibt.
-
4 ist ein Flussdiagramm, das ein Verfahren für die Aufgabenplanung der in 1 gezeigten Roboter beschreibt.
-
EINGEHENDE BESCHREIBUNG
-
Unter Bezugnahme auf die Zeichnungen, bei denen gleichgeartete Bezugszeichen in den gesamten mehreren Ansichten gleiche oder ähnliche Komponenten bezeichnen, stellt 1 ein verteiltes Robotersteuemetzwerk 10 dar. Zum Beispiel kann das Steuernetzwerk 10 wie gezeigt einen beispielhaften humanoiden Roboter 12 und einen herkömmlichen mehrachsigen Roboter 14 und/oder mehr oder weniger Roboter größerer oder geringerer Komplexität relativ zu den Robotern 12, 14 umfassen. Wie hierin dargelegt wird eine konsolidierte Roboteraufgabenplanung für einen oder mehrere Roboter innerhalb des Steuernetzwerks 10 mittels einer Roboteraufgabensteuerungskomponente (RTC) 13 erreicht.
-
Typischerweise wird die Aufgabenplanung über eine verteilte Steuerungsumgebung auf der Ebene jedes der Roboter 12 und 14 durchgeführt, und im Einzelnen nur für diese bestimmten Roboter 12, 14. Die RTC 13 sieht stattdessen, wenn sie wie hierin dargelegt ausgelegt und verwendet wird, eine grafische integrierte Entwicklungsumgebung (IDE) vor, die die Verwendung einer visuellen Programmiersprache (kurz VPL, vom engl. Visual Programming Language) ermöglicht, um neuen Programmiercode zu schreiben. Dies geschieht in einer ersten Ebene, d. h. einer grafischen Anwenderschnittstelle (GUI) 22, die somit für die RTC 13 wie vorstehend erwähnt als grafisches ”Frontend” dient.
-
Die GUI 22, die in einer geeignet konfigurierten Rechnervorrichtung aufgenommen sein kann, ermöglicht einem Anwender das Erzeugen neuer Programmskripte, das Speichern der Skripte als grafische Blöcke und dann nach Bedarf das Starten, Pausieren und Stoppen der Ausführung dieser Blöcke bei Laufzeit, während eine Laufzeitdiagnoserückmeldung erhalten wird. Auf diese Weise kann die GUI 22 sowohl für die Entwicklung als auch das Umsetzen von Anwendungen verwendet werden, wobei der Begriff ”Anwendung” verwendet wird, um jeden Sequenzblock ”höchster Ebene” zu bezeichnen, der zu einer oder mehreren RTC-Skript-Engine(s) 20 abgesetzt werden kann, was wiederum eine zweite Steuerebene vorsieht. Die GUI 22 kann Zugriff auf einen Texteditor (TE) 41, die vorstehend erwähnte VPL und einen Bibliotheksbrowser (B) umfassen oder bieten, der die Skripte und Blöcke anzeigt, die bereits angelegt wurden. Somit ermöglicht die Dichotomie einer grafischen IDE durch eine einzige GUI 2 und potentiell viele verteilte Skript-Engines 20 das Software-Prototyping und Aufgabenplanung auf hoher Ebene über einer verteilten Umgebung. Steuermodule (CM) 21, 31 sehen eine dritte Steuerebene vor, wobei alle drei Ebenen nachstehend näher beschrieben werden. Auch wenn es der Einfachheit halber nicht gezeigt ist, kann die GUI 22 ein zugehöriges Fenster für jeden Block öffnen, wenn in der IDE auf den Block geklickt wird. Nachstehend wird dieses Konzept unter Bezugnahme auf 2 eingehender beschrieben.
-
In einer bestimmten Ausführungsform kann der humanoide Roboter 12 von 1 über 42 Freiheitsgrade (kurz DOF, vom engl. Degree Of Freedom) haben und automatisierte interaktive Aufgaben unter Verwendung anderer integrierter Systemkomponenten wie etwa Klemmen, 2D- oder 3D-Kameras, Leuchten, Relais, etc. mit menschenähnlichen Geschicklichkeitswerten durchführen. Um eine solche Geschicklichkeit zu erreichen, kann der Roboter 12 unabhängig bewegliche und untereinander abhängig bewegliche Robotergelenke umfassen, wie etwa ein Schultergelenk eines Arms 18, ohne darauf beschränkt zu sein. Die Position des Schultergelenks wird allgemein durch Pfeil A angedeutet.
-
Analog ist ein Ellbogengelenk allgemein durch Pfeil B angedeutet, wobei der Roboter 12 auch ein Handgelenk (Pfeil C), ein Nackengelenk (Pfeil D), das einem Kopf 19 eine mehrachsige Bewegung ermöglicht, und ein Taillengelenk (Pfeil E), das eine Bewegung eines Rumpfs 16 ermöglicht, sowie die verschiedenen Fingergelenke (Pfeil F), die zwischen den Fingerknochen jedes Roboterfingers positioniert sind, umfasst. Jedes Robotergelenk enthält einen oder mehrere Aktoren, z. B. Gelenkmotoren, lineare Aktoren, Drehaktoren und dergleichen, und wird von diesem/diesen innen angetrieben. Auch wenn es in 1 der Einfachheit der Veranschaulichung halber nicht gezeigt ist, können die Fingergelenke (Pfeil F) und/oder andere Gelenke mittels Sehnen unter Verwenden von Kugelgewindevorrichtungen angetrieben werden.
-
Im Gegensatz zu dem Roboter 12 kann der mehrachsige Roboter 14 einen viel geringeren Grad relativer Komplexität aufweisen. Zum Beispiel kann sich der Roboter 14 bezüglich nur drei Achsen G, H und I bewegen und/oder kann bezüglich eines festen oder mobilen Unterteils 17 drehen. Ein solcher Roboter wird in der Industrie typischerweise verwendet, um sich wiederholende Aufgaben durchzuführen. Beispielhafte Nutzungen des Roboters 14 können Farbauftrag, Schweißen, Logistik/Materialtransport und dergleichen umfassen. Die zwei beispielhaften Roboter 12 und 14 sollen Roboter mit zueinander erheblich unterschiedlichen Freiheitsgraden veranschaulichen. Die Komplexität der Roboter 12, 14, die tatsächlich als Teil des Steuernetzwerks 10 von 1 verwendet werden, kann abhängig von der Anwendung variieren. Der Einheitlichkeit der Darstellung halber wird hierin nachstehend die vereinfachte beispielhafte Ausführungsform mit zwei Robotern von 1 verwendet.
-
Die Aufgabenausführung für jeden der Roboter 12 und 14 wird direkt mittels der jeweiligen Steuermodule 21, 31 gesteuert, die relativ zu der RTC 13 jeweils eine untere Steuerebene bilden. Die Steuermodule 21 und 31 erzeugen oder akzeptieren bei der Ausführung von angeordneten Aufgaben angeordnete Eingaben oder Steuerreferenzen für die verschiedenen Gelenkaktoren, z. B. Motoren, lineare Aktoren und dergleichen. Während jedes Steuermodul 21, 31 in 1 als einzelne. Rechnervorrichtung gezeigt ist, können die verschiedenen Hardware- und Software-Elemente der Steuermodule 21, 31 bezüglich des gesteuerten Roboters 12, 14 verteilt sein.
-
Zum Beispiel kann jedes Gelenk ein eingebettetes Gelenksteuergerät in der Form einer Leiterplattenbaugruppe aufweisen, die mit einer (nicht gezeigten) Hauptleiterplatte in Verbindung steht. Unabhängig davon, wie die physikalischen Elemente der Steuermodule 21, 31 verteilt sind, umfasst jedes Steuermodul 21, 31 ein oder mehrere Prozessoren 23, 33, ein oder mehrere Sender-Empfänger 27, 37 und ein oder mehrere greifbare, nicht flüchtige Speichervorrichtungen 29, 39. Analog kann jedes Steuermodul 21, 31 eine zugeordnete Anwenderschnittstelle 32, 42 aufweisen, die wie gezeigt einem Anwender Zugriff auf den Roboter 12 oder 14 bietet.
-
Bezüglich der Funktionalität ist jedes Steuermodul 21, 31 ausgelegt, um die Bewegung der Roboter 12, 14 als Reaktion auf erhaltene Aufgabenanordnungen, die von der RTC 13 vorgesehen werden, zu steuern, nachdem alle Blöcke, die den Programmiercode oder das Skript verkörpern, mittels der Skript-Engine(s) 20 verarbeitet wurden. D. h. jedes Steuermodul 21, 31 ist programmiert, ausgestattet und/oder anderweitig physikalisch in der Lage, alle erforderlichen Steuerschritte, die zum Reagieren auf Aufgabenplanungsanordnungen von der RTC 13 erforderlich sind, ohne weitere Abwandlung durchzuführen. Die Steuermodule 21, 31 sehen eine präzise Bewegungssteuerung der feinen und groben Bewegungen vor, die für Aktionen des Roboters 12, 14 erforderlich sind. Die RTC 13 weist jedes Steuermodul 21, 31 effektiv an, was es tun soll, statt wie es dies präzis tun soll. Die Steuermodule 21 und 31 sind programmiert oder anderweitig ausgelegt, um zu ermitteln, wie die von der RTC 13 zugewiesenen Aufgaben der oberen Ebene auszuführen sind.
-
Weiter unter Bezugnahme auf 1 kommunizieren die verschiedenen Steuermodule 21, 31 mit der RTC 13 über eine Netzwerktransportebene (NTL) 25, d. h. die bestimmte Ebene in einem Rechnernetzwerk, die für das Bilden von Datenpaketen und das Liefern der Datenpakete zu den verschiedenen Prozessen und Steuermodulen zuständig ist, wie aus dem Gebiet gut bekannt ist. Die RTC 13 unterstützt mehrere Netzwerkdatenübertragungsprotokolle zum Implementieren der NTL 25, z. B. ROS, ZeroMQ, TCP/IP, UPD, etc. und lässt sich leicht erweitern, um andere auf Forderung der Entwickler durch eine Plug-In-Architektur aufzunehmen, wie aus dem Gebiet bekannt ist. Diese Fähigkeit erleichtert die Integration der RTC 13 bei externer Software und Sensoren, die ihr eigenes bestimmtes Protokoll haben können. Ferner erleichtert der Aufbau und die Funktion der RTC 13, wie sie hierin offenbart ist, eine schnelle Integration von peripheren Eingabesensorikvorrichtungen, wie etwa Kameras, Laserentfernungsmesser, 3D-Tiefensensoren, Kraft-/Drehmomentsensoren, Trägheitsmesseinrichtungen oder Beschleunigungsmessern etc., ohne darauf beschränkt zu sein. Die I/O-Blöcke können einfach ausgelegt werden, um jeder festgelegter Art von sensorischen Daten über die NTL 25, die von einem solchen peripheren Gerät erzeugt werden, ”zuzuhören” oder diese zu ”abonnieren”.
-
Die erforderliche Funktionalität der Skript-Engine(s) 20 umfasst das Koordinieren des Flusses von Programmen, d. h. wie die verschiedenen Blöcke Auslösevorgänge entlang ihrer verschiedenen Verbindungen senden, um neue Blöcke zu starten, des Flusses von Daten zwischen allen Berechnungsknoten in dem Steuernetzwerk 10 und das Sequentialisieren von Referenzbefehlen zu den Steuermodulen 21, 31. Hardware kann einen greifbaren, nicht flüchtigen Speicher (M), einen Prozessor P und einen Sender-Empfänger (T) sowie aufgezeichnete Anweisungen, die zum Ausführen eines Verfahrens 100, wie es in 4 gezeigt und nachstehend beschrieben wird, umfassen. Zusätzliche Hardware kann die A/D-, D/A- und I/O-Schaltungsanordnung, die vorstehend erwähnt wurde, sowie jede anderen erforderliche Hardware und Software umfassen.
-
Wie bei den Steuermodulen 21, 31 können die verschiedenen Skript-Engines 20 der RTC 13 mittels eines oder mehrerer Rechner oder Datenverarbeitungsvorrichtungen ausgeführt werden, die jeweils einen oder mehrere Prozessoren (P), einen greifbaren, nicht flüchtigen Speicher (M) wie etwa einen Festwertspeicher (ROM), einen optischen Speicher, Flash-Speicher und dergleichen sowie einen Arbeitsspeicher (RAM) und einen löschbaren, elektrisch programmierbaren Festwertspeicher (EEPROM) aufweisen. Die verschiedene Hardware der Skript-Engine(s) 20 kann einen. Hochgeschwindigkeitstaktgeber, eine Analog/Digital(A/D)-Schaltungsanordnung, eine Digital/Analog(D/A)-Schaltungsanordnung und jegliche erforderliche Eingangs-/Ausgangs(I/O)-Schaltungsanordnung und -vorrichtungen sowie Signalaufbereitungs- und Pufferelektronik umfassen.
-
Die RTC 13 sieht eine erweiterbare Programmierumgebung zum Entwickeln, Diagnostizieren und Umsetzen neuer Roboteranwendungen innerhalb des Netzwerks 10 von 1 vor. Solche Anwendungen können von einem Roboter oder Sensor genutzt werden, der über die NTL 25 mit der RTC 13 verbunden ist, sei es nun der Roboter 12 hohen Freiheitsgrads oder der Roboter 14 relativ niedrigen Freiheitsgrads oder alle, was dazwischen liegt. Die RTC 13 sieht eine interpretierende Programmierungsumgebung vor, die eine Umgebung ist, in der das Kompilieren eines von einem Rechner ausführbaren Codes weder erforderlich ist noch genutzt wird. In dieser Umgebung können Anwender bestehende Skript-Blöcke zur Aufgabenplanung einfach aus der zentralen Bibliothek, d. h. ”Codebibliothekblöcke”, in neue Anwendungen ”ziehen und ablegen” und/oder neue Aufgabensequenzblöcke anlegen, um neu entstehenden Anforderungen und neuer Hardware gerecht zu werden. Dieses Konzept wird nun unter Bezugnahme auf 2 erläutert.
-
Unter Bezugnahme auf 2 erleichtert die schematisch in 1 gezeigte RTC 13 die Programmentwicklung in der Aufgabenplanungsphase der Steuerung. Während er der Einfachheit halber linear gezeigt ist, könnte ein einzelner Vorgang auch mehrere Blöcke gleichzeitig auslösen, wodurch eine gleichzeitige/parallele Verarbeitungspipeline in Gang gesetzt würde. Hierin wird aber der Einheitlichkeit der Darstellung halber eine lineare Sequenz beschrieben.
-
Ein Anwender der RTC 13 kann die GUI 22 von jeder Rechnervorrichtung aus laden, auf der sie verfügbar ist, und Sourcecode 141 unter Verwenden des Texteditors 41 schreiben. In einer möglichen Ausführungsform kann der Sourcecode 141 unter Verwenden der Python-Programmiersprache geschrieben werden, z. B. Python 3.3.0 oder spätere Versionen, Lua oder andere Skriptsprachen. Python und Lua sind zwei nicht einschränkende Beispiele für interpretierende Programmiersprachen, die für die Anwendungsentwicklung und das Aufgabenprototyping gut geeignet sind und die auf verschiedenen Plattformen, darunter Windows, Linux/Unix, Mac OS X, OS/2 und Amiga, laufen.
-
Merkmale von Python und Lua, die von jeder anderen Skriptsprache geteilt werden sollten, die in alternativen Ausführungsformen verwendet wird, umfassen eine klare, lesbare Syntax und einen natürlichen Ausdruck eines prozeduralen Codes.
-
Ein solcher Code erfordert im Gegensatz zu Nichtskriptsprachen wie C++ keine Kompilier- und Verknüpfungsschritte. Während andere interpretierende Programmiersprachen mittels des Texteditors 41 verwendet werden können, ohne vom gewollten Schutzumfang abzuweichen, würden ähnliche Fähigkeiten die effektive Nutzung der RTC 13 erleichtern. Das beispielhafte Flussdiagramm von 2 umfasst einige grundlegende veranschaulichende Blöcke, einschließlich I/O-Verbindungen und Zustandsidentifikatoren. Jeder Block stellt ein interpretierendes Programm für eine bestimmte Aufgabe oder Funktion der Roboter 12 oder 14 dar. Die spezifische Hardware, die in die bestimmten I/O-Verbindungen eingebunden werden muss, bleibt undefiniert, d. h. ”abstrakt”. Definiert wird nur die Art von Daten, z. B. Gelenkgeschwindigkeit, Gelenkposition, RGBD-Bild, etc., die das Skript eingeben oder ausgeben muss.
-
Ein Anwender schreibt und/oder wählt somit mittels der GUI 22 von 1 Codebibliothekblöcke 44 und legt sie in einem Programmierbildschirm der GUI 22 ab. Ein Klicken auf einen einzelnen Block kann in der GUI 22 ein Fenster öffnen, um Informationen oder Menüs anzuzeigen, z. B. Reiter, die die verschiedenen Skript-Engines 20 anzeigen, die gewählt werden können (ein ”Einstellungs”-Reiter), modifizierbare Parameter, die ein Anwender für diesen bestimmten Fall des Skripts in der aktuellen Aufgabensequenz festlegen kann (einen ”Parameter”-Reiter), etc. Wenn ein Anwender ein neues Skript in dem Texteditor 41 schreibt, gibt es somit Code-”Haken”, die dem Anwender das Anlegen neuer Codevariablen mit Werten erlauben, die zurückgestellt werden, bis der Anwender die Werte dieser Variablen in der Anwendung höherer Ebene, d. h. dem Aufgabensequenzblock 52, definiert. Wenn ein neuer Fall des Skript-Blocks in einen neuen Aufgabensequenzblock 52 gezogen und dort abgelegt wird, werden diese Variablen zusammen mit editierbaren Textfenstern angezeigt. Der Anwender kann dann die Werte dieser Variablen modifizieren, so dass die vom Anwender festgelegten Werte während der Ausführung interpretiert werden.
-
Einzelne Skripte des Sourcecodes 141, die mittels des Texteditors 41 geschrieben werden, wobei jeder einen Schritt oder Schritte einer bestimmten Aufgabe der oberen Ebene beschreibt, können in der zentralen Bibliothek des Speichers in der GUI 22 als Codebibliothekblöcke 44 gespeichert werden, wobei jeder Codebibliothekblock 44 eine visuelle Darstellung des zugrundeliegenden Programmiercodes an einem vorgegebenen Berechnungsknoten in dem System 10 von 1 vorsieht. Jeder Codebibliothekblock 44 kann eine willkürliche Anzahl an Eingangsverbindungen 46 und Ausgangsverbindungen 48 jeweils zu und von anderen Bibliothekblöcken sowie externen Anwendungen aufweisen. Diese Verbindungen erfassen in einer Anwendung während Implementierung die Datenflusspfade in die, aus den und unter den Blöcken 44. Die tatsächliche Anzahl an jeweiligen Eingangs- und Ausgangsverbindungen 46 und 48 kann variieren, wobei der Einfachheit der Darstellung halber jeweils eine gezeigt ist. Die Eingangsverbindung 46 bildet einen Zeiger auf ankommende Daten, z. B. ein Farbbild von einer Kamera, die als Hardware-Element mit einem der Roboter 12 oder 14 von 1 verbunden ist, oder einem Sensor, der eine Gelenkposition liest. Analog ist die Ausgangsverbindung 48 ein Zeiger auf verarbeitete Ausgangsdaten, z. B. eine in schwarz und weiß verarbeitete Version des gleichen Bilds oder ein entsprechender Gelenkbefehl unter Verwenden der gleichen Beispiele. Die RTC 13 von 1 legt somit die Art, aber nicht die Quelle, der verschiedenen Eingänge und Ausgänge für einen vorgegebenen Codebibliothekblock 44 fest.
-
In der IDE, die von der RTC 13 von 1 vorgesehen wird, und wie vorstehend erwähnt kann eine VPL-Umgebung verwendet werden, um bestehende Codebibliothekblöcke 44 in eine erwünschte Aufgabensequenz zu ”ziehen und abzulegen”. Die Aufgabensequenz kann wiederum innerhalb des Speichers (M) von 1 in der Bibliothek gespeichert werden. In 2 ist ein vereinfachtes Beispiel gezeigt, wobei der Codebibliothekblock 44 wie durch Pfeil J angedeutet in ein anderes Fenster ”gezogen und abgelegt” wird, um eine Aufgabensequenz mit anderen Codebibliothekblöcken 144 und 244 zu bilden. Jeder der anderen Codebibliothekblöcke 144 und 244 kann wie der Codebibliothekblock 44 einen Satz von Eingangs- und Ausgangsverbindungen aufweisen. Diese werden als Eingangsverbindungen 146, 246 und Ausgangsverbindungen 148, 248 für die jeweiligen Codebibliothekblöcke 144 und 244 gezeigt.
-
Mehrere jeweilige Eingangs- und/oder Ausgangsverbindungen 46 und/oder 48 in einer vorgegebenen Sequenz können miteinander verknüpft und in dem Aufgabensequenzblock 52 ”höherer Ebene” offengelegt werden. Der Einfachheit halber sind an dem Aufgabensequenzblock 52 I/O-Verbindungen analog zu den Verbindungen 46 und 48 nicht gezeigt, da sie in der GUI 22 der RTC aufgenommen sind, wenn ein solches Offenlegen erfolgt. Wenn zum Beispiel verschiedene Ausgangsverbindungen 46, 146 beide zu den gleichen Bilddaten weisen oder an diese anbinden, könnten die Ausgangsverbindungen 46 und 146 durch Parametrisieren dieser Verbindungen mit dem gleichen Namen in dem Aufgabensequenzblock 52 miteinander verknüpft werden. Um von einer vorgegebenen Skript-Engine 20 ausführbar zu sein, müssen alle Aufgabensequenzblöcke 52 einen Start- und Stoppzustand aufweisen, um die Eintritts- und Austrittspunkte des Programmflusses dieser Sequenz 52 anzudeuten, wenn sie als Anwendung oder als Unteraufgabe in einer Anwendung höherer Ebene laufengelassen wird. Die Aufgabensequenz hat einen Startzustand (0) und einen Endzustand (1). Zwischen einigen oder allen der Codebibliothekblöcke 44, 144, 244 können Sensordaten 50 bei der Ausführung des nächsten Codebibliothekblocks in dieser Sequenz empfangen und verwendet werden, die erneut linear oder nicht linear sein können, z. B. mit einer möglichen gleichzeitigen oder parallelen Ausführung eines oder mehrerer Schritte.
-
Wie durch Pfeil K von 2 angedeutet ist, kann die gesamte Aufgabensequenz in der zentralen Bibliothek in dem Speicher der GUI 22 oder an einer anderen zugänglichen Stelle als Aufgabensequenzblock 52 gespeichert werden. Dadurch kann beim Bauen anderer Aufgabensequenzen der Aufgabensequenzblock 52 durch Ziehen und Ablegen des Aufgabensequenzblocks 52 in ein VPL-Fenster, z. B. der in 1 gezeigten GUI 22, und Schreiben zusätzlicher Codebibliothekblöcke und/oder Ziehen und Ablegen von bestehenden Codebibliothekblöcken wieder verwendet werden. Jemand, der in einem VPL-Fenster arbeitet, könnte auf den Aufgabensequenzblock 52 klicken, um die zugrundeliegende Struktur zu öffnen, die aus zusätzlichen Aufgabensequenzblöcken 52 und/oder Codebibliothekblöcken 44 bestehen kann. Während der Implementierung laden somit, wenn ein Anwender von der GUI 22 an einem vorgegebenen Sequenzblock ”spielen” drückt, alle Blöcke für die Sequenz über die NTL 25 zu einer oder mehreren festgelegten Skript-Engines 20 herunter, wobei sie in den lokalen Speicher M der Skript-Engine(s) laden.
-
Ein Klicken auf einen vorgegebenen Codebibliothekblock jeder Art bewirkt ein Öffnen des Texteditors 41, so dass der zugrundeliegende Code 141 für den Anwender sichtbar ist. Man kann den Texteditor 41 von 2 während der Programmentwicklung verwenden, um einen bestimmten Zustand oder Status eines vorgegebenen Codebibliothekblocks 44 oder eines Aufgabensequenzblocks 52 zum Beispiel einer Farbe wie grün, gelb oder rot zuzuordnen. Mittels der GUI 22 kann man dann später den Status jedes Blocks 44 oder 52 bei Laufzeit einsehen und auf einen vorgegebenen Block 44 oder 52 klicken, um dadurch zur nächsten Ebene der Aufgabensequenz vorzudringen und den Status von Subblöcken in der Anwendungshierarchie in Echtzeit einzusehen.
-
Zunächst kann die zentrale Bibliothek auf der Seite der GUI 22 aufgenommen sein. D. h. etwaige vorbestehende Codebibliothekblöcke 44 können in einem Verzeichnis auf einem Rechner gespeichert werden, auf dem die GUI 22 betrieben wird, und mittels des in 1 gezeigten Dateibrowsers eingesehen werden. Neu angelegte Codebibliothekblöcke 44 können auch in dem gleichen Verzeichnis gespeichert werden. Da man die GUI 22 auf einer anderen physikalischen Vorrichtung als der der verschiedenen Skript-Engines 20, die die zugrundeliegenden Skripte ausführen, laufenlassen könnte, führt das Drücken auf ”spielen”, um eine vorgegebene Aufgabensequenz mittels der GUI 22 zu starten, zu einem Herunterladen aller zugeordneten Codebibliothekblöcke 44 über die NTL 25 zu der erforderlichen Skript-Engine 20/den erforderlichen Skript-Engines 20, wo die Blöcke 44 in einem lokalen Speicher (M) der physikalischen Rechnervorrichtung(en), die jede Skript-Engine 20 bilden, gespeichert werden können.
-
Jede Skript-Engine 20 mit dem Block der obersten Ebene bzw. ”Start”-Block gibt dann einen Auslösebefehl, erneut über die NTL 25, zu allen Skript-Engines 20 in dem Steuernetzwerk 10 von 1 aus. Wenn einige der benachrichtigten Skript-Engines 20 Codebibliothekblöcke 44, die in einer Sequenz mit dem ”Start”-Block verbunden sind, geladen haben, dann beginnen diese bestimmten Skript-Engines 20 mit dem Ausführen dieser Blöcke 44 usw. Für jeden Codebibliothekblock 44 werden die I/O-Verbindungen effektiv die einzigen erforderlichen Plug-Ins vor dem Implementieren zum individuellen Anpassen eines ansonsten abstrakten Aufgabenprogramms, das vollständig aus den einzelnen Codebibliothekblöcken 44 aufgebaut ist, zur Verwendung durch einen spezifischen Roboter 12 oder 14 (siehe 1).
-
Um zu einem vorstehend gemachten Punkt zurückzukehren, bleiben alle Codebibliothekblöcke 44 auf der Ebene der RTC 13 abstrakt, während Aufgabensequenzblöcke 52 abstrakt bleiben können, aber nicht müssen. ”Abstrakte” Blöcke jeder Art sind nicht ohne weiteres von externer Hardware oder Software nutzbar. Somit müssen die RTC 13 und/oder die Steuermodule 21, 31, die mit der RTC 13 über die NTL 25 von 1 verbunden sind, zusätzliche Schritte ergreifen, um diese abstrakten Blöcke auf der Ebene der Steuermodule 21, 31 nutzbar zu machen. Diese Vorgehensweise wird nun unter Bezugnahme auf 3 erläutert.
-
Unter Bezugnahme auf 3 ist ein beispielhaftes Aufgabenplanungsdiagramm 70 gezeigt, das ein vereinfachtes System verwendet, bei dem nur ein Roboter, in diesem Beispiel der Roboter 12, verwendet wird. Das Hinzufügen von zusätzlichen Robotern und zusätzlichen Skript-Engines 20 ändert nicht die vorliegende Vorgehensweise, wenngleich es zusätzliche Berechnungsknoten hinzufügen würde. Der Einfachheit halber ist nur eine Skript-Engine 20 gezeigt, wenngleich wie nachstehend unter Bezugnahme auf 4 erläutert ist, in verschiedenen Ausführungsformen eine beliebige Anzahl an Skript-Engines 20 verwendet werden kann. Die GUI 22 kann verwendet werden, um die erforderlichen Codebibliothekblöcke zum Bauen einer Aufgabe oder einer Aufgabensequenz zu ziehen und abzulegen, wie vorstehend unter Bezugnahme auf 2 erläutert wurde. Der Doppfelkopfpfeil 65 stellt den Zweiwege-Fluss von Informationen zu und von der GUI 22 und der Skript-Engine 20 dar.
-
Das Aufbauen einer vorgegebenen Aufgabensequenz, insbesondere in einer VPL-Umgebung, erzeugt effektiv einen endlichen Automaten. Während der Einfachheit halber eine Maschine mit einem Zustand und somit einem Berechnungsknoten gezeigt ist, können mehr Knoten verwendet werden, wobei jeder Knoten mittels der NTL 25 kommuniziert. Ein endlicher Automat, wie er hierin verwendet wird, ist eine Vorrichtung, die einen Status/Zustand speichert und anhand einer Eingabe arbeiten kann, um diesen Status/Zustand zu ändern, und/oder das Erfolgen einer Maßnahme oder Ausgabe für eine vorgegebene Änderung veranlassen kann.
-
Jede Skript-Engine 20 kommuniziert über die NTL 25 mit dem Roboter 12 ohne Rücksicht auf die bestimmten Betriebssysteme oder Berechnungs-Engines, die von dem Roboter/den Robotern verwendet werden. Bei der Ausführung einer vorgegebenen Aufgabe werden unterschiedliche Hardwarevorrichtungen des Roboters 12 verwendet. Zum Beispiel kann der Roboter 12 eine (nicht gezeigte) 3D-Kamera verwenden, um das in 1 gezeigte Objekt 11 in Vorbereitung auf das Ergreifen des Objekts 11 zu betrachten. Nähe-, Kraft- und/oder andere Sensoren können als Teil der Steuerlogik zum Ausführen eines Greifens verwendet werden, sei es nun des Objekts 11 oder einer anderen Vorrichtung. Daten von den verschiedenen Hardwarevorrichtungen des Roboters 12 werden über die NTL 25 zu der Skript-Engine 20 übertragen. Nachdem ein Hardware-Element einen Wert ausgibt, müssen die Daten zu dem Netzwerk ”veröffentlicht” werden, wie dieser Begriff auf dem Gebiet bekannt ist, so dass alle vernetzten Vorrichtungen oder andere Skript-Engines 20, die über die NTL 25 kommunizieren, auf die Daten zugreifen können.
-
Somit kann jedes Hardware-Modul einen entsprechenden Interpretier-Block (IB) 60, 62, der die Rohdaten interpretiert und sie zu dem Netzwerk veröffentlicht, umfassen. Interpretierblöcke 60, 62 dienen als sensorische Verarbeitungsknoten. Die Interpretierblöcke 60, 62 können alleinstehende Software-Pakete verwenden, wie etwa das Open-Source Robot Operating System (ROS), das von Open Source Robotics Foundation (OSRF) unterhalten wird, d. h. ein Open-Source-Protokoll zum Kommunizieren über die NTL 25 zwischen den verschiedenen Hardwaremodulen und dem Roboter 12, was sowohl Standardmeldungen durchlassende Protokolle als auch Datenarten sowie verschiedene Codebibliotheken oder Module ermöglicht, die Sensordaten verarbeiten oder Roboterverhaltenspläne berechnen können, sind aber nicht darauf beschränkt. D. h. ROS sieht ein Standardnetzwerkprotokoll und Betriebssystemdienste wie etwa Hardwareabstraktion, Vorrichtungstreiber, Bibliotheken, Durchleiten von Meldungen, Paket-Management, Hardwareabstraktion und Steuerung von Vorrichtungen der unteren Ebene vor, wie es aus dem Gebiet gut bekannt ist. Das Meldungen durchleitende Protokoll von ROS kann hierin verwendet werden, um über die NTL 25 auf I/O-Daten zuzugreifen, wenngleich andere externe Vernetzungsbibliotheken verwendet werden können, wie etwa ZeroMQ von iMatix Corporation.
-
Unter Bezugnahme auf 4 ist ein Verfahren 100 für Aufgabenplanung in einer verteilten Umgebung, wie etwa in dem Steuernetzwerk 10 von 1, gezeigt. Beginnend bei Schritt 102 wird die RTC 13 initialisiert, wodurch Netzwerkkonnektivität mit den gesteuerten Robotern hergestellt oder geprüft wird. Dann rückt das Verfahren 100 zu Schritt 104 vor.
-
Schritt 104 bringt den Zugriff auf die zentrale Bibliothek mit sich, die in dem Speicher einer Rechnervorrichtung bestehen kann, der die GUI 22 verkörpert oder beherbergt, z. B. durch Klicken auf ein in einem Fenster der GUI 22 angezeigtes Symbol. Dann rückt das Verfahren 100 zu Schritt 106 vor.
-
Bei Schritt 106 ermittelt ein Anwender, ob die Codebibliothekblöcke 44 in der zentralen Bibliothek für die bestimmte Aufgabe, die geplant wird, vorhanden sind. Wenn nicht, rückt das Verfahren 100 zu Schritt 108 vor. Wenn aber genügend Codebibliothekblöcke 44 in der zentralen Bibliothek vorliegen, rückt das Verfahren 100 stattdessen zu Schritt 112 vor.
-
Bei Schritt 108 kann ein Anwender mittels der GUI 22 ein Programmierfenster öffnen und beginnt Programmiercode zu schreiben, z. B. Python- oder Lua-Code, der für einen vorgegebenen Schritt oder vorgegebene Schritte der Aufgabe geeignet ist. Jeder Schritt der Aufgabe kann bei Schritt 110 als neuer Codebibliothekblock 44 oder Aufgabensequenzblock 52 in der zentralen Bibliothek gespeichert werden. Das Verfahren 100 rückt von Schritt 110 zu Schritt 112 vor, sobald der gesamte notwendige Code geschrieben oder gezogen und abgelegt wurde.
-
Bei Schritt 112 öffnet der Anwender mittels der GUI 22 ein VPL-Fenster und zieht die entwickelten Codebibliothekblöcke 44 und legt sie ab, um eine erwünschte Aufgabensequenz zu bauen. Eine vereinfachte Version davon mit Codebibliothekblöcken 44, 144 und 244 wird in 2 gezeigt und vorstehend beschrieben. Ein oder mehrere Aufgabensequenzblöcke 52 können bei Schritt 114 auf diese Weise gebaut und in der zentralen Bibliothek gespeichert werden, wobei so viele der verknüpften Codebibliothekblöcke 44 wie für die erwünschte Aufgabe erforderlich verwendet werden.
-
Schritt 116 umfasst das Zuordnen der I/O-Vorrichtungen zu den Codebibliothekblöcken 44 mittels des Eingabeblocks 46, der wie vorstehend erwähnt einen Zeiger auf ankommende Daten bildet. Als Teil von Schritt 116 kann der Ausgabeblock 48 ebenfalls zugewiesen werden. Die RTC 13 wird somit bei Schritt 116 verwendet, um die Art der Eingaben und Ausgaben für jeden Codebibliothekblock 44 zu definieren. Als Teil dieses Schritts kann ein Anwender vor dem Implementieren wählen, ob die I/O-Verbindungen ”rückgebunden” werden sollen oder nicht, um auf verschiedene Quellen oder Ziele in dem Datenfluss hinzuweisen. Zum Beispiel könnte man durch Klicken auf den Eingabeblock 46 oder Ausgabeblock 48, der Text anzeigen kann, der jeden zu Variablen in dem Code des bestimmten Blocks zuordnet, erneut binden, zu welchem Zeitpunkt ein Dialogfenster mit einem Textfeld angezeigt werden kann, das es dem Anwender erlaubt, das spezifische Ziel oder die spezifische Quelle einzutippen, d. h. wie vorstehend erwähnt den Zeiger auf die Daten, etwa durch Tippen ”linkes-Auge_Kamera_rgb_Bild” in einem Laufzeitsteuerkontext oder ”rechtes Auge_Kamera_rgb_Bild” in einem anderen.
-
Sobald dies geschehen ist, werden die Aufgaben bei Schritt 118 ausgeführt, der das Herunterladen der Codeblöcke 44 oder 52 zu der erforderlichen Skript-Engine 20/den erforderlichen Skript-Engines 20 von 1 umfasst. Ein Teil dieses Schritts kann das Wählen durch den Anwender der bestimmten Skript-Engine(s) 20, zu der abgeschickt werden soll, umfassen, oder Schritt 118 kann einfach standardmäßig zu einer oder mehreren Skript-Engines 20 gehen. Bei Schritt 118 interpretiert die Skript-Engine(s) 20 den zugrundeliegenden Programmiercode, übertragen etwaige I/O-Daten über die NTL 25 und handhaben etwaige Wechsel zwischen den Aufgabensequenzen und den zugeordneten Codebibliothekblöcken 44.
-
Weiterhin kann, wenn die Skript-Engines 20 von 2 im gesamten Steuernetzwerk 10 der gleichen Figur ”verteilt” sind, ein Anwender, der die gesamte Anwendung einer einzigen Skript-Engine 20 zuweisen will, dies tun. Wenn der Anwender analog jeden einzelnen Codebibliothekblock 44 und/oder Aufgabensequenzblock 52 auf verschiedenen Skript-Engines 20 ausführen möchte, kann der Anwender auch dies oder alles in dem Spektrum zwischen diesen beispielhaften Extremen tun. Wie vorstehend erwähnt ist ein wesentliches Merkmal der RTC 13, die in 1 gezeigt und vorstehend näher beschrieben wird, dass die RTC 13 den Programmfluss aller Aufgabensequenzen selbst in einer Situation handhabt, in der jeder Block 44 oder 52 über dem Steuernetzwerk 10 von 1 verteilt ist. Der Programmfluss zwischen verschiedenen Skript-Engines 20 wird über die NTL 25 gehandhabt. Als Teil des in 4 gezeigten Flusses könnte der Anwender somit bestimmte Blöcke 44 oder 52 spezifischen Skript-Engines 20 zuweisen, um die Verarbeitungseffizienz zu optimieren und die rechnerische Belastung auszugleichen.
-
Letztlich werden bei Schritt 118 alle erforderlichen Steuergeräte der unteren Ebene, z. B. die Steuermodule 21, 31 von 1, angewiesen, eine Maßnahme zu ergreifen, wie etwa ein oder mehrere Gelenke und/oder Greiforgane entsprechend dem Aufgabencode, der von der Skript-Engine 20/den Skript-Engines 20 interpretiert wird, zu bewegen. Bei Erhalt der Aufgabe steuern die Steuermodule 21, 31 danach die verschiedenen Gelenkmotoren und/oder andere Gelenkaktoren nach Bedarf, damit sie sich entsprechend der Aufgabe von der RTC 13 bewegen.
-
Obgleich die besten Ausführungsarten der Erfindung ausführlich beschrieben worden sind, werden Fachleute auf dem Gebiet, das diese Erfindung betrifft, verschiedene alternative Konstruktionen und Ausführungsformen zur praktischen Ausführung der Erfindung innerhalb des Schutzumfangs der beigefügten Ansprüche erkennen.
