DE102014103738B3

DE102014103738B3 - Visuelle fehlersuche bei roboteraufgaben

Info

Publication number: DE102014103738B3
Application number: DE102014103738.3A
Authority: DE
Inventors: Leandro G. Barajas; David W. Payton; Li Yang Ku; Ryan M. Uhlenbrock; Darren Earl
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2014-02-25
Filing date: 2014-03-19
Publication date: 2015-07-16
Anticipated expiration: 2034-03-20
Also published as: US20150239127A1; CN104858876A; US9387589B2; CN104858876B

Abstract

Ein Robotersystem enthält einen Roboter, Sensoren, die Statusinformationen erfassen, welche eine Position und Orientierung des Roboters und eines Objekts innerhalb des Arbeitsraums enthalten, und einen Controller. Der Controller, der eine Arbeitsweise des Roboters visuell auf Fehler untersucht, enthält ein Simulatormodul, ein Aktionsplanermodul und eine graphische Benutzerschnittstelle (GUI). Das Simulatormodul empfängt die Statusinformationen und erzeugt in Ansprechen auf Markierungsbefehle visuelle Markierungen als graphische Darstellungen des Objekts und des Roboters. Ein Aktionsplanermodul wählt eine nächste Aktion des Roboters. Das Markierungsgeneratormodul erzeugt die Markierungsbefehle und gibt diese in Ansprechen auf die gewählte nächste Aktion an das Simulatormodul aus. Die GUI empfängt die visuellen Markierungen, die gewählte zukünftige Aktion und die Eingabebefehle und zeigt diese an. Mit Hilfe des Aktionsplanermoduls werden die Position und/oder die Orientierung der visuellen Markierungen in Echtzeit modifiziert, um die Arbeitsweise des Roboters zu verändern.

Description

TECHNISCHES GEBIET
Die vorliegende Offenbarung betrifft die visuelle Fehlersuche bei Roboteraufgaben.
HINTERGRUND
Roboter sind elektromechanische Vorrichtungen, die zum Manipulieren von Objekten unter Verwendung einer Reihe von Gliedern, Aktoren und Greiforganen in der Lage sind. Die Glieder eines Roboters sind typischerweise mit Hilfe von Gelenken miteinander verbunden, wobei jedes von diesen durch einen oder mehrere Gelenkaktoren voneinander unabhängig oder abhängig angetrieben werden kann. Jedes Gelenk stellt eine unabhängige Steuerungsvariable oder einen Freiheitsgrad dar. Greiforgane sind die speziellen Vorrichtungen, die verwendet werden, um eine befohlene Arbeitsaufgabenabfolge auszuführen, etwa das Ergreifen eines Arbeitswerkzeugs oder das Stapeln von einer Komponente auf eine andere.
Alle Modifikationen an einem Objekt, das von einem Roboter beim Ausführen einer gegebenen Arbeitsaufgabenabfolge gehandhabt wird, erfordert typischerweise ein umfassendes Neutrainieren des Roboters. Dies kann auch dann zutreffen, wenn sich die Oberflächen des ergriffenen Objekts in einer anschließenden Arbeitsaufgabenabfolge nicht verändern. Auf ähnliche Weise können Veränderungen bei der Positionierung oder Orientierung eines Objekts in der Arbeitsumgebung eines Roboters als Folge eines Fehlers und/oder lockererer Betriebsbedingungen ein umfassendes Neutrainieren des Roboters erfordern, sei es über eine Programmierung oder über ein manuelles Neutrainieren des Roboters durch ein Rückwärtsbewegen der Gelenke und eine Aufgabendemonstration. Jedoch lässt sich eine existierende Steuerungssoftware nicht einfach umrüsten, um Anforderungen aufgrund sich verändernder Flexibilität zu erfüllen.
Die Druckschrift DE 697 35 269 T2 offenbart ein Steuerungsverfahren für einen schrittweisen Betrieb eines Roboters, bei dem ein Roboter an einer Graphikanzeigevorrichtung, die mit einer Robotersteuerung verbunden ist, angezeigt wird und über eine mit der Graphikanzeigevorrichtung verbundene Zeigevorrichtung im Tippbetrieb gesteuert werden kann.
In der Druckschrift DE 696 03 009 T2 ist ein Bediengerät zum Einlernen eines Roboters offenbart, das eine Anzeigeeinrichtung umfasst, auf der durch Roboterprogrammierschritte verursachte Bewegungen des Roboters grafisch dargestellt werden und eine Bewegung des Roboters über Eingaben an die Anzeigeeinrichtung gesteuert werden kann.
Die Druckschrift US 6 330 495 B1 offenbart ein Offline-Lernverfahren zum Einlernen mehrerer Roboter, die einander teilweise überschneidende Aktionsräume aufweisen, wobei Modelle aller betroffenen Roboter angezeigt werden, jeder Roboter graphisch gewählt und eingelernt werden kann und mögliche Kollisionen/Störungen in den einander teilweise überschneidenden Aktionsräumen automatisch berücksichtigt werden.
In der Druckschrift JP 2011-189 431 A ist ein Robotersystem offenbart, bei dem ein Bediengerät zum Einlernen eines Roboters über eine eingebaute Kamera Bilder des Roboters aufnimmt und diese mit einem 3D-Modell des Roboters abgeglichen werden, sodass der Roboter mithilfe eines berührungsempfindlichen Bildschirms des Bediengeräts manuell gesteuert werden kann.
Die Druckschrift JP 2006-350 602 A offenbart ein Bediengerät mit einem berührungsempfindlichen Bildschirm für eine Vorrichtung zur Entnahme von Objekten aus einer Gußform, bei dem die Vorrichtung auf dem Bediengerät graphisch angezeigt wird und über Fingerbewegungen auf dem berührungsempfindlichen Bildschirm bewegt werden kann.
Die Aufgabe der Erfindung besteht darin, ein Robotersystem bereitzustellen, das einem Bediener die Möglichkeit gibt, anhand einer Visualisierung aktuell geplanter Aktionen in den geplanten Ablauf des Roboterprogramms in Echtzeit einzugreifen, um Korrekturen vorzunehmen.
Diese Aufgabe wird durch die Robotersysteme der Ansprüche 1 und 9 gelöst.
ZUSAMMENFASSUNG
Es wird hier ein Robotersystem offenbart. Das Robotersystem enthält einen Roboter und einen Controller mit einer graphischen Benutzerschnittstelle (GUI). Der Controller ist so ausgestaltet, d. h. ausreichend mit Hardware ausgestattet und in Software programmiert, dass er ermöglicht, dass ein Bediener/Benutzer des Robotersystems gegenwärtige und künftige Aktionen des Roboters auf visuelle Weise ”debugged” bzw. nach Fehlern darin sucht, speziell mit Hilfe der Manipulation eines Satzes von angezeigten visuellen Markierungen. Die vorliegende Herangehensweise soll eine Benutzerinteraktion mit geplanten Aktionen des Roboters in einer simulierten Umgebung ermöglichen.
In der modernen Produktion besteht eine fortlaufende Bestrebung, flexible Montagelinien zu erreichen, die in der Lage sind, neue oder stärker veränderte Produkte mit einem minimalen Betrag an Stillstandszeit zu erzeugen. Das Robotersystem der vorliegenden Erfindung spricht dieses Bedürfnis teilweise mit Hilfe einer Funktionalität zur intuitiven graphischen Planung von Aktionen an. Die visuellen Markierungen, die in dem Robotersystem in allen seinen offenbarten Ausführungsformen verwendet werden, ermöglichen, dass Benutzer auf visuelle Weise die Genauigkeit geplanter zukünftiger Aufgaben oder Aktionen des Roboters untersuchen, um widerstreitende Aktionen zu vermeiden, indem geplante Greiforgantrajektorien für diese Aktionen zeitlich vor den Aktionen beobachtet werden, und um die geplanten Aktionen zu justieren, indem die visuellen Markierungen mit Hilfe der GUI in Echtzeit verändert werden.
Der beschriebene Controller kombiniert ein Aktionsplanermodul mit einem Simulatormodul, um verschiedene Wettbewerbsvorteile bereitzustellen. Beispielsweise können alle möglichen Aktionstrajektorien und zukünftigen Roboter- und Objektpositionen und -Orientierungen mit Hilfe der visuellen Markierungen in einer simulierten Umgebung dargestellt werden, die mit Hilfe eines Anzeigebildschirms der GUI betrachtet werden kann. Indem die Aktionsplaner- und Simulatormodule zusammengefasst werden, ermöglicht der Controller eine Visualisierung aller aktuell geplanten Aktionen und er ermöglicht außerdem notwendige Steuerungsjustierungen mit Hilfe der GUI. Dies wiederum ermöglicht, dass ein Benutzer das Verhalten des Roboters in Echtzeit verändert. Das heißt, dass ein Benutzer alle möglichen zukünftigen Aktionen des Roboters schnell erkennen kann und schnell feststellen kann, ob das Aktionsplanermodul eine wünschenswerte Lösung gewählt hat. Eine derartige Herangehensweise kann die Ausführung von Arbeitsaufgabenabfolgen mit mehreren Schritten, etwa das Stapeln von Objekten, sowie komplexere Arbeitsaufgaben in einer sich konstant verändernden Arbeitsumgebung ermöglichen.
Bei einer beispielhaften Ausführungsform kann das Robotersystem einen Roboter, der auf Eingabebefehle anspricht, Sensoren, die einen Satz von Statusinformationen messen, und einen Controller enthalten. Die Statusinformationen können eine Position und eine Orientierung des Roboters und eines Objekts, das sich innerhalb eines Arbeitsraums des Roboters befindet, enthalten. Der Controller enthält einen Prozessor und einen Speicher, in dem Anweisungen zur visuellen Fehlersuche in bzw. zum visuellen Debuggen einer Operation des Roboters aufgezeichnet sind. Der Controller enthält ein Simulatormodul, ein Aktionsplanermodul, ein Markierungsgeneratormodul und eine GUI.
Das Simulatormodul empfängt die Statusinformationen von den Sensoren und gibt visuelle Markierungen als eine graphische Darstellung des Objekts und des Roboters im Arbeitsraum aus. Das Aktionsplanermodul wählt zukünftige Aktionen des Roboters. Das Markierungsgeneratormodul gibt Markierungsbefehle an das Simulatormodul aus. Die GUI, die einen Anzeigebildschirm enthält, empfängt die visuellen Markierungen und die gewählte zukünftige Aktion und zeigt diese an, und sie empfängt außerdem die Eingabebefehle. Mit Hilfe der GUI und des Aktionsplanermoduls können die Position und/oder Orientierung der visuellen Markierungen von einem Benutzer in Echtzeit modifiziert werden, um die Arbeitsweise des Roboters zu verändern.
Es wird auch ein Verfahren zur visuellen Fehlersuche im Roboter offenbart. Das Verfahren umfasst, dass mit Hilfe eines Simulatormoduls der Satz von Statusinformationen von den Sensoren empfangen wird, dass mit Hilfe eines Markierungsgeneratormoduls mehrere Markierungsbefehle an das Simulatormodul übertragen werden, und dass visuelle Markierungen in Ansprechen auf die Markierungsbefehle mit Hilfe des Simulatormoduls als graphische Darstellungen des Objekts und des Roboters im Arbeitsraum erzeugt werden. Das Verfahren umfasst außerdem, dass die visuellen Markierungen und die gewählte zukünftige Aktion auf einem Anzeigebildschirm einer GUI angezeigt werden, dass eine zukünftige Aktion des Roboters mit Hilfe eines Aktionsplanermoduls gewählt wird, und dass mit Hilfe des Aktionsplanermoduls die Position und/oder die Orientierung der visuellen Markierungen in Echtzeit in Ansprechen auf Eingabesignale modifiziert werden, um dadurch die Arbeitsweise des Roboters zu verändern.
Die vorstehenden Merkmale und Vorteile und andere Merkmale und Vorteile der vorliegenden Erfindung ergeben sich leicht aus der folgenden genauen Beschreibung der besten Arten, um die Erfindung auszuführen, wenn sie in Verbindung mit den beiliegenden Zeichnungen gelesen wird.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 ist eine schematische Darstellung eines Robotersystems und eines Controllers, welche eine Funktionalität zur visuellen Fehlersuche, die hier beschrieben wird, bereitstellen.
1A ist eine schematische Darstellung von beispielhaften Logikelementen, die innerhalb der Struktur des Controllers des in 1 gezeigten Robotersystems verwendbar sind.
2 ist eine schematische Veranschaulichung in perspektivischer Ansicht eines beispielhaften ersten Zustands der visuellen Fehlersuche für den Controller von 1, welche sich nähernde und sich weg bewegende Trajektorienmarkierungen zeigt.
3 ist eine schematische Veranschaulichung in perspektivischer Ansicht eines beispielhaften zweiten Zustands der visuellen Fehlersuche, der Objektmarkierungen nach dem Ergreifen eines Objekts zeigt.
4 ist eine schematische Veranschaulichung in perspektivischer Ansicht eines beispielhaften dritten Zustands der visuellen Fehlersuche, die Kollisionsmarkierungen zeigt.
5 ist ein Flussdiagramm, das eine beispielhafte Ausführungsform eines Verfahrens zur visuellen Fehlersuche in einer Roboteraufgabe mit Hilfe des in 1 gezeigten Robotersystems beschreibt.
GENAUE BESCHREIBUNG
Mit Bezug auf die Zeichnungen, bei denen gleiche Bezugszeichen in den mehreren Ansichten gleiche oder ähnliche Komponenten bezeichnen, ist in 1 auf schematische Weise ein beispielhaftes Robotersystem 10 mit einem Roboter 12 gezeigt. Bei einer beispielhaften Ausführungsform kann der Roboter 12 ein Produktionsroboter sein, der betrieben werden kann, um Materialhandhabungs- oder Montageaufgaben auszuführen, beispielsweise ein Sechsachsenroboter der Art, die in der Technik bekannt ist, oder ein autonomer geschickter Roboter mit mindestens sechs Freiheitsgraden. Aktionen des Roboters 12 können mit Hilfe eines Controllers 50 (CTRL) wie nachstehend beschrieben visuell auf Fehler untersucht werden. Der Controller 50 führt Anweisungen aus, die ein Verfahren 100 verkörpern, wobei ein Beispiel dafür in 5 gezeigt ist. Beispielhafte Bildschirme einer graphischen Benutzerschnittstelle (GUI) 52 zur graphischen oder visuellen Fehlersuche in einer ”virtuellen Welt” sind in 2–4 dargestellt, wobei diese Figuren alle nacheinander nachstehend erörtert werden.
Wie in der Technik bekannt ist, sind herkömmliche Greiforgane so konstruiert, dass sie in einer hochgradig strukturierten Arbeitsumgebung mit einem minimalen Betrag an Abweichung arbeiten. Greiforgane sind oft auf eine Bewegung mit Hilfe starr definierter Trajektorien beschränkt. Beispielsweise können Annäherungstrajektorien und Wegbewegungstrajektorien für jede neue Roboteraufgabe programmiert werden. Auf ähnliche Weise sind Industrieroboter oft mit einem festgelegten Satz von gewünschten Bewegungen programmiert. Folglich wird bei derartigen Systemen eine Planung von zukünftigen Aktionen nicht verwendet. Zudem verlassen sich herkömmliche Roboter tendenziell darauf, dass Objekte in ihrer Arbeitsumgebung in einer konsistenten und in hohem Maß vorhersagbaren Weise platziert werden. Diese Einschränkungen führen daher dazu, dass herkömmliche Herangehensweisen zur Robotersteuerung relativ unflexibel und in Echtzeit schwer zu modifizieren sind.
Auch Robotersysteme, die eine sensorische Rückmeldung zur autonomen Trajektorienplanung beinhalten, benötigen eine erhebliche Interaktion mit Programmierern, um die Roboteraufgabe korrekt zu identifizieren, die benötigten Bewegungsparameter zu justieren, die benötigten Greifpositionen des Manipulators festzulegen und Aufgabentrajektorien an kritischen Stellen zu justieren. Die vorliegende Herangehensweise soll die Zeit zur Fehlersuche und Entwicklung für Robotersysteme reduzieren, die ein komplexes Aktionsplanungssystem erfordert, beispielsweise durch Vereinfachen von Benutzerinteraktionen.
Der in 1 gezeigte Roboter 12 kann eine Basis 14 enthalten, die an einer Oberfläche 11 positioniert ist, etwa einer Oberfläche des Fußbodens einer Produktionsanlage. Der Roboter 12 kann einen beweglichen Arm 16 mit einem oder mehreren Segmenten 18 enthalten. Ein Greiforgan 20 ist an einem Ende des Segments 18 des Arms 16 positioniert, das mit Bezug auf die Basis 14 das distalste bzw. das am weitesten entfernte ist. Das Greiforgan 20 kann bei einer beispielhaften Ausführungsform ein Robotergreifer sein, der mehrere Finger 27 aufweist, die zum Ergreifen eines Objekts 23 geeignet sind.
Robotergelenke 17 verbinden die verschiedenen Armsegmente 18. Jedes Robotergelenk 17 kann durch einen Gelenkaktor 19, etwa einen Motor angetrieben werden, um das Greiforgan 20 während der Ausführung einer befohlenen Arbeitsaufgabenabfolge (Pfeil 88) zu bewegen. Rohsensordaten (Pfeil 15), die aktuelle Roboterverhaltenswerte beschreiben, werden an den Controller 50 weitergeleitet und von dem Controller 50 verwendet, um aktuelle und zukünftige Aktionen des Roboters 12 in Echtzeit aktiv zu überwachen und visuell zu debuggen. Die Rohsensordaten (Pfeil 15) können Verhaltens- und Zustandswerte des Roboters 12 beschreiben. Beispielhafte Elemente für die Rohsensordaten (Pfeil 15) können ein gemessenes oder befohlenes Drehmoment der Gelenkaktoren 19, eine von dem Greiforgan 20 auf das Objekt 23 aufgebrachte Klemmkraft, eine Geschwindigkeit und/oder eine Beschleunigung des Greiforgans 20 und/oder von beliebigen seiner Gelenkaktoren 19 usw. umfassen.
Zur Erfassung derartiger Daten kann ein Sensorfeld 33 aus einem oder mehreren Sensoren mit dem Roboter 12 verbunden oder daran positioniert sein, etwa an der Basis 14. Das Sensorfeld 33 kann Kraft-, Druck- und/oder Temperatursensoren, Drehmomentsensoren, Beschleunigungsmesser, Positionssensoren und dergleichen enthalten. Das Sensorfeld 33 kann außerdem sogenannte ”weiche” Sensoren enthalten, z. B. eine Software, die Werte aus direkt gemessenen Werten auf indirekte Weise berechnet, wie in der Technik gut verstanden wird. Zudem kann ein Umgebungssensor 25 wie etwa ein Sichtsystem mit Bezug auf den Roboter 12 positioniert und ausgestaltet sein, um alles in seinem Gesichtsfeld (Pfeil V), z. B. das Verhalten des Roboters 12 in seiner Arbeitsumgebung oder seinem Arbeitsraum, als Umgebungsinformationen (Pfeil 26) zu filmen, auf Video aufzunehmen, bildlich zu erfassen und/oder auf andere Weise aufzuzeichnen, welche an den Controller 50 übertragen werden.
Auf die Funktionalität des Controllers 50 von 1 kann mit Hilfe der GUI 52 zugegriffen werden. Daher kann die GUI 52 als Mensch-Maschine-Schnittstelle mit einem Anzeigebildschirm 55, etwa einem berührungsempfindlichen Bildschirm, einem Monitor oder einer anderen visuellen Anzeigevorrichtung ausgeführt sein, die betrieben werden kann, um Steuerungseingaben (Pfeil 53) von einem Benutzer zu empfangen. Die GUI 52 kann außerdem betrieben werden, um Steuerungseingabebefehle (Pfeil CC) zu übertragen und um Rückmeldungsinformationen (Pfeil FB) zu empfangen, wie nachstehend erläutert wird. Der Controller 50 kann Logikelemente 54 zur visuellen Fehlersuche in bzw. zum Debuggen von Operationen des Roboters 12, wie in 1A gezeigt ist, sowie beliebige notwendige Prozessanweisungen, die zum Ausführen des vorliegenden Verfahrens 100 geeignet sind, enthalten.
Der Controller 50 von 1 kann als ein oder mehrere digitale Computer ausgeführt sein, der einen oder mehrere Prozessoren (P) und konkreten, nicht vorübergehenden Speicher (M), beispielsweise Festwertspeicher (ROM), optischen Speicher, magnetische Massenspeichermedien usw. sowie genügend Speicher mit wahlfreiem Zugriff (RAM), elektrisch programmierbaren Festwertspeicher (EPROM) und dergleichen aufweist. Der Controller 50 kann außerdem einen Hochgeschwindigkeits-Taktgeber, Analog/Digital-Schaltungen (A/D-Schaltungen), Digital/Analog-Schaltungen (D/A-Schaltungen) und beliebige benötigte Eingabe/Ausgabe-Schaltungen (I/O-Schaltungen), I/O-Vorrichtungen und Kommunikationsschnittstellen sowie Signalaufbereitungs- und Pufferelektronik enthalten. Eine Eingabevorrichtung 13 kann von der GUI 52 getrennt oder darin integriert sein. Die Eingabevorrichtung 13 kann beispielsweise eine 3D-Maus, ein Joystick oder eine andere Steuerungsvorrichtung sein, die geeignet ist, um den Roboter 12 mit Hilfe von Eingabevorrichtungssignalen (Pfeil 22) vor oder während der Verwendung des vorliegenden Verfahrens 100 zu bewegen oder rückwärts zu verfahren.
Das heißt, dass der Roboter 12 von 1 ”geteacht” werden kann, um eine spezielle Arbeitsaufgabenabfolge auszuführen, mit Hilfe einer von Menschen unterstützten Demonstration und eines von Menschen unterstützten Lernens. Es können visuelle Markierungen programmiert und aufgezeichnet werden, die Merkmale der Arbeitsumgebung repräsentieren, in welcher der Roboter 12 arbeitet, beispielsweise die physikalische Umgebung des Roboters 12. Derartige visuelle Markierungen können reale Objekte repräsentieren, die in der Arbeitsumgebung vorhanden sind, etwa wie gezeigt ein beispielhaftes Objekt 23 oder ein anderes Objekt 21. Außerdem speichert der Controller 50 ein Motorschema 28 im Speicher (M), wobei das Motorschema 28 die erforderlichen Aktionen oder Fähigkeiten des Roboters 12 beschreibt. Das Motorschema 28 kann bei der automatischen Ausführung einer Arbeitsaufgabenabfolge durch die visuellen Markierungen geführt werden, um die tatsächliche Umgebung des Roboters 12 zu berücksichtigen, wie sie beispielsweise von den Umgebungssensoren 25 wahrgenommen wird, wie nachstehend beschrieben ist.
Daher können dem Roboter 12 als eine Voraussetzung für das Ausführen des vorliegenden Verfahrens 100 alle erforderlichen Greifpositionen und Annäherungs/Wegbewegungsrichtungen geteacht werden, während er lernt, wie ein Objekt, beispielsweise das Objekt 23, ergriffen werden soll. Diese Trainingsinformationen werden zur Laufzeit mit allen Markierungen verknüpft, die von dem Controller 50 beliebigen wahrgenommenen Merkmalen zugewiesen wurden, welche mit Hilfe der Umgebungssensoren 25 oder von anderen Sensoren in der Umgebung, in welcher der Roboter 12 arbeitet, detektiert wurden. Daher kann der Roboter 12 zunächst alle notwendigen Markierungen mit Hilfe einer menschlichen Demonstration lernen und der Controller 50 kann diese zunächst aufzeichnen, und danach verknüpft der Controller 50 auf dynamische Weise gelernte Markierungen mit beliebigen detektierten Wahrnehmungsmerkmalen in der Arbeitsumgebung des Roboters 12. Diese Funktionalität ermöglicht eine schnelle Anpassung auf eine sich verändernde Umgebung, während dennoch ermöglicht wird, dass der Roboter 12 einen mehrschrittigen Montageprozess abschließt.
Ein Beispiel für das Erlernen einer Aufgabe unabhängig davon, ob sie mit Hilfe eines ”Handprogrammiergeräts” in einer von Menschen demonstrierten Aufgabe oder anderweitig befohlen wird, ist eine einfache Ergreifen- und Aufnehmen-Aufgabe, bei der der Roboter 12 von 1 das Greiforgan 20 verwendet, um das Objekt 23 zu ergreifen und anzuheben. Ein Benutzer des Roboters 12 kann das Greiforgan 20 in eine mit Bezug auf das Objekt 23 gewünschte Position rückwärts verfahren oder den Roboter 12 mit Hilfe der Benutzereingabevorrichtung 13 und der Eingabevorrichtungssignale (Pfeil 22) bewegen und dann das Objekt 23 unter Verwendung des Greiforgans 20 korrekt ergreifen, beispielsweise indem die Finger 27 manuell oder automatisch mit ausreichender Kraft betätigt werden, um eine geeignete Griffpose herzustellen. Dann bewegt der Benutzer den Arm 16 und das Greiforgan 20, um das Objekt 23 aufzunehmen und zu bewegen.
Obwohl der Roboter 12 von 1 potentiell Aufgabenabfolgen und einige relevante Wahrnehmungsdaten einfach dadurch identifizieren kann, dass er einen menschlichen Bediener beobachtet, der die Aufgabe ausführt, besteht einer der herausfordernderen Teile des Handhabens von neuen Objekten und des Erzeugens neuer Anordnungen darin, zu bestimmen, wo das Greiforgan 20 platziert werden soll und wie ein Werkzeugmittelpunkt in eine korrekte Platzierung gebracht werden kann. Indem man einen menschlichen Bediener den Arm 16 und das Greiforgan 20 auf manuelle Weise durch jede Aufgabe hindurch bewegen lässt, während der Roboter 12 seine eigenen Rohsensordaten (Pfeil 15) mit Hilfe des Controllers 50 aufzeichnet, kann jede Demonstration einen wertvollen Datenstrom mit Erfahrungen bereitstellen, aus dem der Roboter 12 diese schwierigen Probleme bei einer Nachverarbeitung lösen kann, d. h. bei dem Schritt im unmittelbaren Anschluss an das von Menschen unterstützte Erlernen.
Mit Bezug auf Roboterfähigkeiten beruht die Verhaltensnachahmung einer demonstrierten Arbeitsaufgabe auf dem Erkennen und Wiederholen bekannter Roboterfähigkeiten wie etwa dem Ergreifen des Objekts 23, dem Absetzen des Objekts 23 usw. Jede Fähigkeit im Repertoire des Roboters 12 von 1, das als das Motorschema 28 ausgeführt und im Speicher (M) gespeichert sein kann, kann teilweise durch eine Kostenschätzungsfunktion und das Motorschema 28 definiert werden. Für Nachahmungszwecke ist der Ursprung jeder Fähigkeiten nicht von Bedeutung. Die Fähigkeit kann entweder erlernt oder vorprogrammiert sein.
Hinsichtlich der Kostenschätzung gibt eine beispielhafte Kostenschätzungsfunktion, beispielsweise (M_a, E, W_t), die Kosten für das Verknüpfen einer gegebenen Markierung M_a mit einem gegebenen Objekt W_t und den Satz von allen erkannten Endzuständen E zurück, wobei W_t der aktuelle Zustand der Umgebung des Roboters ist, der definiert ist durch: W_t = {P(t), J(t), sensors(t)} wobei P(t) der Satz von allen Objekten ist, die bei Zeitschritt t visuell identifiziert und lokalisiert werden, J(t) die aktuellste Gelenkwinkelkonfiguration des Roboters 10 ist und sensors(t) der Satz von Daten ist, der von allen anderen verfügbaren Sensoren zurückgegeben wird, die in Verbindung mit dem Roboter 12 verwendet werden. Das Motorschema 28 von 1 verwendet die Markierung M_a, ein damit verknüpftes Objekt P_b und den aktuellen Zustand des Roboters 12, um die nächsten Gelenkwinkel zu bestimmen, die an den Roboter 12 gesendet werden sollen, z. B. als die Arbeitsaufgabenabfolge (Pfeil 88). Die tatsächliche Konfiguration des Controllers 50 ist nicht wichtig, sofern ein Weg existiert, um die aktuellen Gelenkwinkel des Roboters 12 zu schätzen, um eine Roboterbewegung immer dann zu verändern, wenn visuelle Markierungen (M_a) zur Laufzeit neu verknüpft werden. Mit dem Hintergrund des Robotertrainings und der Verwendung von Markierungen, die vorstehend allgemein beschrieben wurden, wird die vorliegende Herangehensweise zur visuellen Fehlersuche in einem Robotersystem 10, die ausgestaltet ist, um derartige Markierungen zu verwenden, nun mit Bezug auf 1A–5 beschrieben.
Mit Bezug auf 1A verwendet der Controller 50 die Logikelemente 54, um Operationen des Roboters 12 von 1 in Echtzeit, beispielsweise zur Laufzeit, visuell zu debuggen. Die Logikelemente 54 enthalten mehrere Logikmodule 60, 70 und 80, wobei die graphische Benutzerschnittstelle (GUI) 52 mit den Logikmodulen 60, 70 und 80 in Verbindung steht. Da alle drei Logikmodule 60, 70 und 80 integrale Bestandteile des Controllers 50 von 1 sind, ob als eine Einheit oder in verteiltem Sinn, umfasst der Begriff ”Logikmodul”, so wie er hier verwendet wird, sämtliche Hardware, z. B. Prozessoren, Speicher, I/O-Vorrichtungen usw. und Software, die zum Ausführen erforderlicher Aufgaben der speziellen Module 60, 70 oder 80 notwendig sind, wie nachstehend offengelegt wird.
Das Logikmodul 60 wird hier nachstehend als das Markierungsgeneratormodul (MGEN) 60 bezeichnet. Das Logikmodul 70 ist ein Simulatormodul, das hier nachstehend als das Simulatormodul (SIM) 70 bezeichnet wird. Das Logikmodul 80 ist ein Aktionsplanermodul, das hier nachstehend als das Aktionsplanermodul (AP) 80 bezeichnet wird. Das vorliegende Steuerungsschema kann beispielsweise in der MICROSOFT Robotics Developer Software (MRDS) oder einer anderen geeigneten Software implementiert werden. Die in 1A schematisch gezeigten Logikelemente 54 sind diejenigen, die speziell auf eine visuelle Fehlersuche gerichtet sind, und daher sind andere nicht darauf bezogene Hardware- und Softwareelemente des Controllers 50 der Einfachheit und verbesserten Klarheit halber in 1A weggelassen.
Die visuelle Wahrnehmung im Controller 50 von 1 ist selbst eine Mischung aus Fähigkeiten, die jeweils eine Echtzeitrückmeldung von verschiedenen Robotersensoren für eine aktive Steuerung, Bilder oder andere Umgebungsdaten (Pfeil 26) von simulierten oder realen Kameras, etwa den Umgebungssensoren 25, und Objektpositionen, die direkt von dem Prozessor (P) und dem Speicher (M) des Controllers 50 geholt werden, verwenden. Die folgende Beschreibung betrifft eine einzige Roboterfähigkeit, beispielsweise einen einfachen Griff. Im Allgemeinen stellt die Greiffähigkeit eine gute Vorlage für das Implementieren vieler Roboterfähigkeiten bereit, wobei das Lösen aus einem Griff eine ähnliche Arbeitsaufgabe ist. Andere Fähigkeiten, etwa Verbundaktionen, können als eine Erweiterung des Ergreifens und Loslassens aufgebaut sein und werden vom Fachmann auf diesem Gebiet leicht verstanden.
Das Markierungsgeneratormodul 60 von 1A kann betrieben werden, um Markierungsmodelle oder visuelle Markierungen (Pfeil 62), die mit den Aktionen des in 1 gezeigten Roboters 12 verknüpft sind, zu erzeugen und auszugeben. Wenn die visuellen Markierungen (Pfeil 62) in das Simulatormodul (SIM) 70 eingefügt werden, stellen sie eine graphische Anzeige, z. B. ein Symbol, ein Bild oder eine Cartoon-Darstellung von aktuellen und zukünftigen Aktionen des Roboters 12 bereit. Die visuellen Markierungen (Pfeil 62) können speziellen Objekten zugeordnet sein, die der Roboter 12 besucht oder besuchen wird, und zeigen Attribute des Objekts mit Bezug auf eine geplante Aktion des Roboters 12 an. Markierungsattribute können beispielsweise die Position des Roboters 12 oder eine Position, Orientierung oder Trajektorie eines Objekts wie etwa des Objekts 21 oder 23 von 1 in einem aktuellen oder zukünftigen Zustand anzeigen. Das Visualisierungsattribut einer Markierung (Pfeil 62) kann jede 3D-Form sein, etwa eine Kiste, ein Kegel, oder ein Pfeil, wobei verschiedene Farben optional verschiedene Aspekte der Markierungen (Pfeil 62) repräsentieren.
Kurz mit Bezug auf 2 kann eine halbtransparente Schattierung von Markierungsformen für die Markierungen (Pfeil 62) von 1A verwendet werden, um zu ermöglichen, dass ein Objekt 123 mit Bezug auf die Form einer gegebenen Markierung innerhalb der Markierungsform selbst sichtbar bleibt. Innerhalb des Umfangs der vorliegenden Erfindung sind vier Arten von Markierungen und deren Attribute möglich: eine Zielmarkierung (G), Trajektorienmarkierungen (A, D), eine Zielvorgabemarkierung (O₁, O₂ in 3) und eine Kollisionsmarkierung (C₁, C₂ in 4). Alle visuellen Markierungen werden nacheinander beschrieben.
Die grundlegendste Verwendung der visuellen Markierungen (Pfeil 62 von 1A) besteht darin, Objekte, die innerhalb des Arbeitsraums des Roboters 12 von 1 vorhanden sind und die für aktuelle oder zukünftige Aktionen des Roboters 12 relevant sind, hervorzuheben. Die Zielmarkierung (G) soll ein Objekt hervorheben, z. B. das Objekt 123 von 2, welches das Ziel einer beabsichtigten Aktion ist. Ein Ziel, das durch eine Zielmarkierung (G) repräsentiert wird, kann beispielsweise ein Becher bei einer beispielhaften Einfüllaktion sein, ein unteres Objekt bei einer Stapelaktion wie in 2–4 gezeigt, oder ein Befestigungselement bei einer Befestigungsaktion. Die Zielmarkierungen (G) ermöglichen es Benutzern, in Situationen, bei denen der Roboter 12 von 1 mit einem speziellen Ziel arbeiten soll, oder in Situationen, bei denen der Roboter 12 mit allen möglichen Zielen in seiner Arbeitsumgebung arbeiten soll, zu prüfen, ob das Ziel tatsächlich korrekt ist.
In 2 stellt die Region, die das zu ergreifende Objekt 123 umgibt, eine Visualisierung der Zielmarkierung (G) für die nächste Aufnahmeaktion des Roboters 12 bereit. Die Pfeile A und D sind Trajektorienmarkierungen, welche eine Annäherungstrajektorie (A) und eine Wegbewegungstrajektorie (D) für eine Greifaktion bezüglich einer Aktion des Roboters 12 mit Bezug auf die Zielmarkierung (G) anzeigen. Die Trajektorienmarkierungen (A, D) ermöglichen daher, dass ein Benutzer visuell erkennen kann, ob entlang der Pfade der angezeigten Trajektorien (A, D) Hindernisse vorhanden sind. Andere Objekte 223, 323 auf der Oberfläche 11 können in der Arbeitsumgebung dargestellt sein, welche in Abhängigkeit von der Aufgabe Hindernisse sein können oder auch nicht, beispielsweise ein Hindernis für das Greiforgan 20, wenn es sich dem Objekt 123 annähert.
Wie in 3 gezeigt ist, zeigen die Zielvorgabenmarkierungen (O₁, O₂) an, wo sich ein Objekt in zukünftigen Schritten befinden wird. Wenn Aktionen durch das Aktionsplanermodul 80 von 1A geplant werden, kann eine oder können mehrere Zielvorgabenmarkierungen (O₁, O₂) verwendet werden, um alle Objekte in der Endposition zu zeigen, in der sie sich befinden sollen, nachdem sie durch den Roboter 12 manipuliert wurden. Dies kann immer dann nützlich sein, wenn von dem Roboter 12 eine komplexe Montageaufgabe gehandhabt werden muss, da ein Benutzer zukünftige erwartete Positionen von Objekten leicht bewerten kann und er den Roboter 12 stoppen kann, wenn die Zielvorgabenmarkierungen (O₁, O₂) ein gewünschtes Endergebnis nicht zeigen. in 3 zeigen die Zielvorgabenmarkierungen (O₁, O₂) endgültige Objektpositionen nach einer Manipulation durch den Roboter 12 bei einer beispielhaften Stapelaktion.
Mit Bezug auf 4 repräsentieren Kollisionsmarkierungen (C₁, C₂) ein beispielhaftes Greiforgan 20 in der Form eines Greifers des Roboters 12. Die Kollisionsmarkierung C₂ zeigt, wie ein derartiger Greifer bei zukünftigen Aktionen mit dem Objekt 23 kollidieren könnte. Der Aktionsplaner (AP) von 1A kann dazu beitragen, dass der Roboter 12 ungültige Aktionen vermeidet, die durch Hindernisse in seinem Arbeitsraum blockiert werden, wenn der Roboter 12 das Hindernis korrekt wahrnimmt. Jedoch kann Signalrauschen, z. B. von dem Umgebungssensor 25 von 1 bewirken, dass eine gültige Aktion als ungültig erkannt wird. Daher können die Kollisionsmarkierungen (C₁, C₂) zeigen, wo und wie der Roboter 12 mit Objekten kollidieren wird, indem sie ein Modell des Roboters 12 und der Objekte, z. B. 23, 123, 223, 323 an Positionen zeigen, bei denen eine Kollision bei beliebigen zukünftigen Aktionen auftreten wird. Diese visuelle Darstellung kann für eine visuelle Fehlersuche nützlich sein, wenn der Roboter 12 eine gültige Aktion aufgrund möglicher Kollisionen stoppt.
Wieder mit Bezug auf 1A kann das Simulatormodul (SIM) 70 als 3D-Simulator ausgeführt sein, der Informationen von drei verschiedenen Modellen enthält, d. h. einem Umgebungsmodell (EM) 72, welches Informationen über die umgebende Umwelt von den Umgebungssensoren 25 oder anderen Sensoren verarbeitet, einem Robotermodell (RM) 74, das Informationen über den Zustand und die Bewegung des Roboters 12 beispielsweise mit Hilfe des in 1 gezeigten Sensorfelds 33 verarbeitet, und einem Markierungsmodell (MM) 76, welches die Markierungen (Pfeil 62) empfängt und verarbeitet und eine visuelle Darstellung derselben mit Hilfe der GUI 52 liefert. Folglich präsentiert das Simulatormodul 70 den Roboter 12, Objekte in der Umgebung des Roboters 12 und Markierungen in einer simulierten Welt auf der Grundlage der drei Modelle 72, 74 und 76.
Das Simulatormodul 70 von 1A kann Rotorpositionen und Gelenkwinkel/eine Gelenkrotation des Roboters 12, die gemeinsam als Pfeil X₁₂ dargestellt sind, von dem Sichtsystem 25 und dem Sensorfeld 33 des Robotersystems 10 von 1 und außerdem die Position und Orientierung von allen Objekten in der Umgebung durch die Sensoren 25 oder andere interne oder externe Sensoren empfangen. Das Simulatormodul 70 von 1A aktualisiert seine Modelle jedes Mal, wenn es neue Daten von dem Robotersystem 10, von den Umgebungssensoren 25 oder von dem Sensorfeld 33 empfängt. Das Simulatormodul 70 von 1A aktualisiert außerdem das Markierungsmodell 76 immer dann, wenn das Simulatormodul 70 neue Daten vom Markierungsgeneratormodul 60 mit Hilfe der Markierungen (Pfeil 62) empfängt.
Die GUI 52 kann betrieben werden, um eine simulierte 3D-Welt des Roboters 12 von einem beliebigen benutzergewählten Blickpunkt aus darzustellen und sie ermöglicht außerdem, dass der Benutzer Aktionen des Roboters 12 justiert, indem er die visuellen Markierungen durch eine Interaktion mit der GUI 52 verändert. Vier mögliche Arten der Verwendung sind die Modifikation von Trajektorien, die Modifikation von Zielen, die Modifikation von zukünftigen Positionen und die Fehlersuche in Markierungen.
Bei der Modifikation von Trajektorien ermöglicht die GUI von 1A, dass ein Benutzer die Trajektorie einer Aktion verändert, indem er die Trajektorienmarkierung verändert, d. h. die Pfeile A und D in 2. Dies gibt dem Benutzer die Fähigkeit, den Roboter 12 beim Vermeiden von Hindernissen zu unterstützen, die durch seine Sensoren nicht wahrgenommen werden, die Annäherungsrichtung manuell zu modifizieren, wenn sich die Umgebung verändert, ohne den Roboter 12 neu zu trainieren, und die Länge einer Annäherungstrajektorie (Pfeil A von 2) zu verändern, um entweder die Aktionszeit zu reduzieren oder einen stabileren Annäherungspfad bereitzustellen.
Zur Modifikation von Zielen ermöglicht die GUI 52 von 1A außerdem, dass der Benutzer das Ziel einer gegebenen Roboteraktion verändert, indem er eine Zielmarkierung (G von 2) verändert, wieder mit Hilfe von Steuerungseingabebefehlen (Pfeil 53) an die GUI 52. Dies gibt dem Benutzer die Möglichkeit, zwischen verschiedenen Zielen in Echtzeit umzuschalten.
Außerdem ist eine Modifikation von zukünftigen Positionen mit Hilfe der GUI 52 möglich, um zu ermöglichen, dass der Benutzer die künftige Position verändert, in der sich das Objekt nach einer Manipulation durch den Roboter 12 befinden würde. Dies kann erreicht werden, indem entweder der Ort oder die Orientierung von einer oder mehreren Zielvorgabenmarkierungen (O₁, O₂ von 3) verändert wird. Diese Aktion gibt dem Benutzer die Fähigkeit, die endgültigen Orte der Objekte zu justieren, wenn das Aktionsplanermodul 80 von 1A einen nicht geeigneten Plan ausführt.
Zur Fehlersuche in Markierungen zeigt die GUI 52 von 1A außerdem Informationen über die Aktionen des Roboters immer dann an, wenn eine Markierung von einem Benutzer angewählt wird, wobei eine derartige Anwählaktion ein möglicher Steuerungseingabebefehl (Pfeil 53) an die GUI 52 ist. Dies ermöglicht, dass der Benutzer Fehler leichter und schneller suchen kann, wenn eine spezielle Aktion nicht korrekt ist.
Das Aktionsplanermodul 80, das in 1A gezeigt ist, ist ausgestaltet, um die beste Aktion für den Roboter 12 unter Verwendung von Informationen in der simulierten Welt, die von dem Simulatormodul 70 erzeugt wird, zu wählen. Das Aktionsplanermodul 80 kann zwei Teile enthalten: eine optionale Zustandsvorhersage (SP) 82 und eine Aktionsauswahl (AS) 84. Die Zustandsvorhersage 82 ist programmiert, um auf der Grundlage von Konsequenzen von Aktionen ”Zustände der zukünftigen Welt” zu erzeugen. Eine derartige Vorrichtung kann nützlich sein, wenn von dem Controller 50 eine Aktionsplanung auf der Grundlage einer Vorhersage der Zukunft verwendet wird. Die Aktionsauswahl 84 wählt dann auf der Grundlage von Aufgabeninformationen (Pfeil 78) vom Simulatormodul 70 und den erzeugten Weltzuständen (Pfeil 83) von der Zustandsvorhersage 82 eine nächste Aktion aus, die der Roboter 12 ausführen soll.
Wie vorstehend erwähnt, ist die Verwendung der Zustandsvorhersage 82 optional. Ohne die Zustandsvorhersage 82 kann das Aktionsplanermodul 80 immer noch funktionieren, beispielsweise, indem ein gieriger Algorithmus verwendet wird, der eine nächste verfügbare Aktion mit den geringsten gegenwärtigen Kosten auswählt. Eine beispielhafte Kostenfunktion ist vorstehend beschrieben. Das Markierungsgeneratormodul 60 wäre in diesem Fall immer noch in der Lage, alle Markierungen (Pfeil 62) mit der Ausnahme von allen Objektmarkierungen, die zukünftige Objektpositionen in einem zukünftigen Zustand repräsentieren, zu erzeugen. Wenn die Zustandsvorhersage 82 jedoch implementiert ist, wird das Aktionsplanermodul 80 in der Lage sein, die Aktion zu wählen, die nach mehreren Aktionsschritten zu den niedrigsten Kosten führt.
Die Zustandsvorhersage 82 kann alle möglichen Zustände der zukünftigen Welt mit Hilfe eines Zustandsbaums bis zu einer bestimmten Tiefe erzeugen, wie auf dem Gebiet bekannt ist. Beispielhafte Zustandserzeugungsschritte der optionalen Zustandsvorhersage 82 können wie folgt vorgehen. In einem ersten Schritt kann der aktuelle Zustand des Simulatormoduls 70 aus den Informationen (Pfeil 78) als die Wurzel eines Zustandsbaums verwendet werden, wobei dieser Begriff in der Technik bekannt ist. Dann können alle gültigen Aktionen für jeden Zweig des Zustandsbaums mit Hilfe des Controllers 50 aufgefunden werden, was alle neuen Zustände der Welt erzeugt, die durch jede Aktion des Roboters 12 verändert werden, und er fügt sie als Blätter zu dem entsprechenden Zweig des Zustandsbaums hinzu. Dies wird wiederholt, bis der Zustandsbaum eine kalibrierte Tiefe erreicht hat. Wenn ein neuer Zustand der Welt erzeugt wird, werden alle Informationen in der simulierten Welt geklont und dann in Übereinstimmung damit, wie die Aktion definiert ist, nach Bedarf verändert.
Die Aktionsauswahl 84 des Aktionsplanermoduls 80 sucht die nächste auszuführende Aktion, welche die niedrigsten Kosten aufweist, beruhend auf der aktuellen simulierten Welt vom Simulatormodul 70 und den zukünftigen Zuständen der Welt (Pfeil 83), die von der Zustandsvorhersage 82 erzeugt werden, wenn sie verwendet wird. Wenn die Zustandsvorhersage 82 nicht verwendet wird, wählt das Aktionsplanermodul 80 die nächste Aktion (Pfeil 86) für den Roboter 12, welche die niedrigsten Übergangskosten plus Aktionskosten aufweist. So, wie sie hier verwendet werden, sind die Übergangskosten die Kosten dafür, dass sich der Roboter 12 von 1 von seiner aktuellen Position zu einer ”Bereit”-Position bewegt, bei der der Roboter 12 in der Lage ist, die Aktion auszuführen. Sie sind für gewöhnlich so konstruiert, dass sie proportional zu der Länge der Trajektorie des Roboters 12 sind, die benötigt wird, um sich in die Bereit-Position zu bewegen. Die Aktionskosten können von dem Benutzer in Übereinstimmung mit unterschiedlichen Aktionsklassen angegeben werden. Beispielsweise können bei einer Montageaufgabe einer nächsten Aktion (Pfeil 86), die zwei Teile kombiniert, negative Kosten gegeben werden, was äquivalent für eine Belohnung des Roboters 12 für das Ausführen dieser Arten von Aktionen ist. Wenn die Zustandsvorhersage 82 verwendet wird, wählt das Aktionsplanermodul 80 die spezielle Aktion, die nach einer vorbestimmten Anzahl von Aktionen zu den niedrigsten Kosten führen wird.
Die Aktionsauswahl 84 kann eine Suche auf dem Zustandsbaum starten, der durch die Zustandsvorhersage 82 erzeugt wurde. Wenn ein Knoten im Zustandsbaum erreicht wird, werden die Ausführungskosten jedes Kinderknotens berechnet. Die Ausführungskosten sind als die Summe der Übergangskosten, der Aktionskosten und der Knotenkosten des Kindknotens definiert. Die Übergangskosten und die Aktionskosten sind Kosten, die mit jeder Aktion verbunden sind, die zu dem Kind knoten führt. Die Knotenkosten eines Knotens sind die minimalen Ausführungskosten aus allen Kinderknoten des Knotens. Der Controller 50 kann die Ausführungskosten dieses Knotens gleich den minimalen Ausführungskosten aus allen Kinderknoten für diesen speziellen Knoten setzen. Die Aktion, die zu dem Kind mit den minimalen Ausführungskosten führt, wird als die Aktion mit den niedrigsten Kosten dieses Knotens gesetzt. Die vorstehenden Schritte werden rekursiv wiederholt, bis sie für alle Knoten im Zustandsbaum ausgeführt wurden. Die Aktion mit den niedrigsten Kosten des Wurzelknotens des Zustandsbaums wird dann die gewählte Aktion sein.
Nachdem die Aktion mit den niedrigsten Kosten von dem Controller 50 gewählt ist, sendet die Aktionsauswahl 84 des Aktionsplanermoduls 80 einen Aktionsbefehl an den Roboter 12, z. B. als die Arbeitsaufgabenabfolge (Pfeil 88). Die Aktionsauswahl 84 kann eine gewählte Aktion außerdem auf der Grundlage der Veränderungen modifizieren oder justieren, die an dem Markierungsmodell in dem Simulatormodul 70 durch die GUI 52 vorgenommen wurden. Da Objekte in der Umgebung zu einem beliebigen Zeitpunkt verändert werden können, kann es sein, dass die vorhergehenden Schritte zu einem beliebigen Zeitpunkt während der Ausführung wiederholt werden müssen, so dass eine korrigierte Aktion gewählt werden kann, die dem neuen Zustand entspricht.
Mit Bezug auf 5 beginnt das Verfahren 100 gemäß einer beispielhaften Ausführungsform bei Schritt 102, bei dem der Controller 50 von 1 Eingabebefehle (REC CC) für eine gegebene Arbeitsaufgabenabfolge empfängt. Schritt 102 kann umfassen, dass angefordert wird, dass der Roboter 12 eine einfache Stapelaktion ausführt, wie in 2–4 dargestellt ist. Nachdem die Anforderung gestellt wurde, geht das Verfahren 100 zu Schritt 104 weiter.
Bei Schritt 104 verarbeitet der Controller 50 (PROC) die empfangene Anforderung mit Hilfe des Prozessors (P). Als Teil dieses Schritts kann das in 1 gezeigte Motorschema 28 verwendet werden, um die Anforderung zu bewerten. Bei Schritt 104 empfängt der Controller 50 von 1 die Rohsensordaten (Pfeil 15) von dem Sensorfeld 33 und die Umgebungsdaten (Pfeil 26) von den Umgebungssensoren 25 und verarbeitet diese. In 1A sind diese Informationen gemeinsam als Pfeile X_E und X₁₂ gezeigt. Dann geht das Verfahren 100 zu Schritt 106 weiter.
Schritt 106 umfasst, dass die Markierung (Pfeil 62) mit Hilfe des Markierungsgeneratormoduls 60 von 1A erzeugt wird. Die Umgebungs- und Roboterinformationen, die an den Controller 50 geliefert werden, d. h. die Pfeile X_E und X₁₂, werden mit Hilfe des Umgebungsmodells 72 bzw. des Robotermodells 74 empfangen und verarbeitet. Die erzeugten Markierungen (Pfeil 62) werden auf dem Anzeigebildschirm 55 der GUI 52 dargestellt, wobei diese Übertragung an den Anzeigebildschirm 55 in 5 mit Hilfe eines Pfeils angezeigt ist. Die Arbeitsweise der Logikelemente 54, die zum Erzielen dieses Ergebnisses benötigt werden, ist vorstehend mit Bezug auf 1A im Detail beschrieben. Sobald die Umgebung, der Roboter 12 und alle Markierungen (Pfeil 62 von 1A) an dem Anzeigebildschirm 55 dargestellt sind, geht das Verfahren 100 zu Schritt 108 weiter.
Bei Schritt 108 stellt ein Benutzer des Robotersystems 10 von 1 mit Hilfe der Informationen, die an dem Anzeigebildschirm 55 als Rückmeldungsinformationen (Pfeil FB) angezeigt werden, fest, ob die geplanten zukünftigen Aktionen korrekt sind, wie in 5 mit Hilfe der Notation ”OK?” angezeigt ist. Wenn dies zutrifft, geht das Verfahren 100 zu Schritt 110 weiter. Anderenfalls geht das Verfahren zu Schritt 112 weiter.
Schritt 110 umfasst das Ausführen der befohlenen Arbeitsaufgabe (PT) mit Hilfe der Übertragung der Arbeitsaufgabenabfolge (Pfeil 88 von 1 und 1A). Dann kehrt das Verfahren 100 zu Schritt 102 zurück.
Schritt 112 umfasst, dass die Eingabebefehle (Pfeil 53) in die GUI 52 eingegeben werden, um eine Korrekturaktion (CA) anzufordern. Schritt 112 kann umfassen, dass beliebige oder alle visuellen Markierungen (Pfeil 62) verändert werden, um eine zukünftige Aktionsabfolge zu verändern. Eine Modifikation der Markierungen (Pfeil 62) kann eine Überprüfung jedes Programmiercodes auslösen, der benötigt wird, um ein derartiges verändertes Ergebnis zu erreichen. Das heißt, dass Schritt 112 das Verändern der Markierungen umfassen kann, ähnlich wie das Trainieren des Roboters 12, wie er sich durch eine spezielle Abfolge bewegen soll, mit Hilfe eines Rückwärtsfahrens oder anderer manueller Trainingstechniken, um ein virtuelles Rückwärtsfahren des Roboters 12 zu befehlen. Beispielsweise kann ein Verändern der Zielvorgabenmarkierungen (O₁, O₂ von 3) oder einfach ein Modifizieren der Trajektorienmarkierungen (A, D von 2) den Roboter 12 anweisen, wie er sich in einer zukünftigen Arbeitsaufgabenabfolge bewegen soll.
Die hier vorstehend mit Bezug auf 1–4 beschriebene Verwendung des Robotersystems 10 soll eine Herangehensweise zur visuellen Fehlersuche in Roboteraufgaben mit Hilfe einer Darstellung von Details darüber, wie ein Roboter auf ein Objekt in seinem Arbeitsraum einwirkt, bereitstellen. Die Darstellung der Zielvorgaben in einem virtuellen Raum in Verbindung mit Markierungen, die geplante Trajektorien des Roboters 12 zeigen, ermöglicht einem Benutzer, wahrzunehmen, ob fehlerhafte Ziele geplant sind. Ein Benutzer ist daher in der Lage, die Intention des Roboters 12 von 1 zu sehen, bevor der Roboter 12 eine Aktion tatsächlich durchführt. Eine derartige Herangehensweise kann in einem Robotersystem wie etwa dem Robotersystem 10 von 1 besonders nützlich sein, bei welchem der Roboter 12 nicht mit speziellen Koordinaten und Steuerungspunkten programmiert ist, sondern sich stattdessen zu Objekten als Referenzpunkten bewegt und autonome Aktionen ergreift.
Obwohl die besten Arten zum Ausführen der Erfindung im Detail beschrieben wurden, wird der Fachmann auf dem Gebiet, das diese Erfindung betrifft, verschiedene alternative Konstruktionen und Ausführungsformen erkennen, um die Erfindung im Umfang der beigefügten Ansprüche in die Praxis umzusetzen.

Claims

Robotersystem (10), umfassend: einen Roboter (12), der auf Eingabebefehle (53) anspricht; Sensoren (25, 33), die einen Satz von Statusinformationen erfassen, der eine Position und eine Orientierung des Roboters (12) und eines Objekts (23) innerhalb des Arbeitsraums enthält; und einen Controller (50) mit einem Prozessor (P) und einem Speicher (M), in dem Anweisungen zur visuellen Fehlersuche in einem Betrieb des Roboters (12) aufgezeichnet sind, wobei der Controller (50) enthält: ein Simulatormodul (70) in Verbindung mit den Sensoren (25, 33), wobei das Simulatormodul (70) den Satz von Statusinformationen von den Sensoren (25, 33) empfängt und in Ansprechen auf Markierungsbefehle visuelle Markierungen (62) als graphische Darstellungen des Objekts (23) und des Roboters (12) im Arbeitsraum erzeugt; ein Aktionsplanermodul (80), das ausgestaltet ist, um eine nächste Aktion des Roboters (12) zu wählen; ein Markierungsgeneratormodul (60) in Verbindung mit dem Aktionsplanermodul (80), das ausgestaltet ist, um die Markierungsbefehle für das Simulatormodul (70) in Ansprechen auf die gewählte nächste Aktion des Roboters (12) zu erzeugen und auszugeben; und eine graphische Benutzerschnittstelle (GUI) (52) mit einem Anzeigebildschirm (55), wobei die GUI (52) mit dem Simulatormodul (70) in Verbindung steht und betrieben werden kann, um die visuellen Markierungen (62) zu empfangen und anzuzeigen, und um die Eingabebefehle (53) zu empfangen und mit Hilfe des Aktionsplanermoduls (80) die Position und/oder die Orientierung der visuellen Markierungen (62) in Echtzeit zu modifizieren, um die Arbeitsweise des Roboters (12) zu verändern, wodurch die Arbeitsweise visuell auf Fehler untersucht wird; wobei die visuellen Markierungen (62) mindestens eines enthalten von: eine Zielmarkierung (G), die ein gewünschtes Ziel eines Greiforgans (20) des Roboters (12) anzeigt, mindestens eine Trajektorienmarkierung (A, D), die eine Annäherungstrajektorie (A) oder eine Wegbewegungstrajektorie (D) des Greiforgans (20) anzeigt, eine Zielvorgabenmarkierung (O1, O2), die anzeigt, wo sich das Objekt (23) in der Zukunft befinden wird, und eine Kollisionsmarkierung (C1, C2), die anzeigt, wo das Greiforgan (20) mit dem Objekt (23) kollidieren wird.
Robotersystem (10) nach Anspruch 1, wobei die visuellen Markierungen (62) ein Paar der Trajektorienmarkierungen (A, D) enthalten, und wobei das Paar der Trajektorienmarkierungen (A, D) einen ersten Pfeil (A), der die Annäherungstrajektorie des Greiforgans (20) anzeigt, und einen zweiten Pfeil (D), der die Wegbewegungstrajektorie des Greiforgans (20) anzeigt, enthält.
Robotersystem (10) nach Anspruch 1, wobei die visuelle Markierung (62) eine halbtransparente Form enthält, welche das Objekt (23) umgibt, die ermöglicht, dass das Objekt (23) innerhalb der halbtransparenten Form sichtbar bleibt.
Robotersystem (10) nach Anspruch 1, wobei die Sensoren (25, 33) einen Umgebungssensor (25) enthalten, der betrieben werden kann, um Bilder des Objekts (23) und des Roboters (12) zu erfassen und um die erfassten Bilder an das Simulatormodul (70) als Teil des Satzes von Statusinformationen auszugeben.
Robotersystem (10) nach Anspruch 1, wobei das Aktionsplanermodul (80) ein Aktionsauswahlmodul (84) und ein Zustandsvorhersagemodul (82) enthält, wobei das Aktionsplanermodul (80) die nächste Aktion des Roboters (12) unter Verwendung von Aufgabeninformationen (78) vom Simulatormodul (70) wählt und das Zustandsvorhersagemodul (82) ausgestaltet ist, um zukünftige Zustände des Roboters (12) unter Verwendung der Aufgabeninformationen (78) vorherzusagen.
Robotersystem (10) nach Anspruch 5, wobei das Zustandsvorhersagemodul (82) einen Zustandsbaum verwendet, um die zukünftigen Zustände vorherzusagen.
Robotersystem (10) nach Anspruch 5, wobei das Aktionsplanermodul (80) ausgestaltet ist, um die nächste Aktion unter Verwendung eines Kostenmodells als eine Aktion mit den niedrigsten Kosten zu bestimmen.
Robotersystem (10) nach Anspruch 1, wobei das Simulatormodul (70) ein Markierungsmodell (76) enthält, das betrieben werden kann, um die Markierungsbefehle in zweidimensionale und dreidimensionale visuelle Markierungen (62) umzuwandeln.
Robotersystem (10), umfassend: einen Roboter (12), der auf Eingabebefehle (53) anspricht und ein Greiforgan (20) aufweist; Sensoren (25, 33), die einen Satz von Statusinformationen erfassen, der eine Position und eine Orientierung des Roboters (12) und eines Objekts (23) innerhalb des Arbeitsraums enthält; und einen Controller (50) mit einem Prozessor (P) und einem Speicher (M), in dem Anweisungen für eine visuelle Fehlersuche in einer Operation des Roboters (12) aufgezeichnet sind, umfassend: ein Simulatormodul (70) in Verbindung mit den Sensoren (25, 33), wobei das Simulatormodul (70) den Satz von Statusinformationen von den Sensoren (25, 33) empfängt und in Ansprechen auf Markierungsbefehle einen Satz von visuellen Markierungen (62) als graphische Darstellungen des Objekts (23) und des Roboters (12) im Arbeitsraum erzeugt; ein Aktionsplanermodul (80), das ausgestaltet ist, um zukünftige Aktionen des Roboters (12) unter Verwendung eines Kostenmodells als eine Aktion mit niedrigsten Kosten zu wählen, wobei das Aktionsplanermodul (80) ein Aktionsauswahlmodul (84) enthält, das eine nächste Aktion des Roboters (12) unter Verwendung von Aufgabeninformationen (78) von dem Simulatormodul (70) wählt; ein Markierungsgeneratormodul (60) in Verbindung mit dem Aktionsplanermodul (80), das ausgestaltet ist, um die Markierungsbefehle an das Simulatormodul (70) in Ansprechen auf die gewählte nächste Aktion auszugeben; und eine graphische Benutzerschnittstelle (GUI) (52) mit einem Anzeigebildschirm (55), wobei die GUI (52) mit dem Simulatormodul (70) in Verbindung steht und betrieben werden kann, um die visuellen Markierungen (62) und die gewählte zukünftige Aktion zu empfangen und anzuzeigen, und um außerdem die Eingabebefehle (53) zu empfangen und um mit Hilfe des Aktionsplanermoduls (80) die Position und/oder die Orientierung der visuellen Markierungen (62) in Echtzeit zu modifizieren, um die Arbeitsweise des Roboters (12) zu verändern, wodurch die Arbeitsweise visuell auf Fehler untersucht wird; wobei die visuellen Markierungen (62) eine Zielmarkierung (G), die ein gewünschtes Ziel des Greiforgans (20) anzeigt, eine Trajektorienmarkierung (A, D), die einen Annäherungstrajektorienpfeil (A) und einen Wegbewegungstrajektorienpfeil (D) als Trajektorien des Greiforgans (20) anzeigt, eine Zielvorgabenmarkierung (O1, O2), die anzeigt, wo sich das Objekt (23) in der Zukunft befinden wird, und eine Kollisionsmarkierung (C1, C2), die anzeigt, wo das Greiforgan (20) mit dem Objekt (23) kollidieren wird, enthalten, und wobei die Zielmarkierung (G) und/oder die Zielvorgabenmarkierung (O1, O2) und/oder die Kollisionsmarkierung (C1, C2) eine halbtransparente Form enthält bzw. enthalten, die das Objekt (23) umgibt, die ermöglicht, dass das Objekt (23) innerhalb der halbtransparenten Form sichtbar bleibt.