CADMatch¶

Einleitung¶

Das CADMatch-Modul ein optional erhältliches Modul, welches intern auf dem rc_visard läuft.

Bemerkung

Das Modul ist optional und benötigt eine eigene Lizenz, welche erworben werden muss.

Dieses Modul bietet eine gebrauchsfertige Lösung für die 3D-Objekterkennung anhand von CAD-Templates und liefert Greifpunkte für allgemeine Greifer. Die Objekte können sich in einer Kiste (Bin, Load Carrier) oder frei platziert im Erfassungsbereich der Kamera befinden.

Für jedes Objekt, das mit dem CADMatch-Modul erkannt werden soll, wird ein Template benötigt. Um Templates zu erhalten, setzen Sie sich bitte mit dem Roboception Support (Kontakt) in Verbindung.

Das CADMatch-Modul bietet darüber hinaus:

eine intuitiv gestaltete Bedienoberfläche für Inbetriebnahme, Konfiguration und Test auf der rc_visard Web GUI
eine REST-API-Schnittstelle und eine KUKA Ethernet KRL Schnittstelle
die Möglichkeit, sogenannte Regions of Interest (ROIs) zu definieren, um relevante Teilbereiche der Szene auszuwählen (siehe Region of Interest Funktionalität)
eine integrierte Behältererkennung (siehe Load Carrier Funktionalität), um in Bin-Picking-Anwendungen („Griff in die Kiste“) Greifpunkte nur für Objekte in dem erkannten Behälter zu berechnen
die Unterstützung von Behältern mit Fächern, sodass Greifpunkte für Objekte nur in einem definierten Teilvolumen des Behälters berechnet werden
die Definition von Greifpunkten für jedes Template über eine interaktive Visualisierung in der Web GUI
die Unterstützung von sowohl statisch montierten als auch robotergeführten Kameras. Optional kann es mit der Hand-Auge-Kalibrierung kombiniert werden, um Greifposen in einem benutzerdefinierten externen Koordinatensystem zu liefern.
eine Sortierung der Greifpunkte nach ihrer Erreichbarkeit, sodass die besten Greifpunkte zuerst zurückgeliefert werden

Setzen von Greifpunkten¶

Das CADMatch-Modul erkent 3D-Objekte in einer Szene basierend auf einem CAD-Template und liefert die Posen der Objektursprünge zurück. Um das CADMatch-Modul direkt in einer Roboteranwendung zu nutzen, können für jedes Template Greifpunkte definiert werden. Ein Greifpunkt repräsentiert die gewünschte Position und Orientierung des Roboter-TCPs (Tool Center Point), mit der das Objekt gegriffen werden kann (siehe fig-cadmatch-grasp-points).

Definition von Greifpunkten bezogen auf den Roboter-TCP

Jeder Greifpunkt enthält eine id, die eindeutig über alle Greifpunkte eines Objekt-Templates sein muss, die ID des Templates (template_id), zu dem der Greifpunkt hinzugefügt wird, und die Greifpose (pose) im Koordinatensystem des Templates. Greifpunkte können über die REST-API-Schnittstelle, oder über die interaktive Visualisierung in der Web GUI definiert werden. Der rc_visard kann bis zu 50 Greifpunkte pro Template speichern.

Setzen von Greifpunken in der Web GUI¶

Die rc_visard Web GUI bietet eine interaktive und intuitive Möglichkeit, Greifpunkte für Objekt-Templates zu setzen. Im ersten Schritt muss das Objekt-Template auf den rc_visard hochgeladen werden. Das kann über die CADMatch-Seite (unter der Seite Module) in der Web GUI erfolgen, indem im Abschnitt Templates und Greifpunkte auf neues Template hinzufügen geklickt wird. Wenn der Upload abgeschlossen ist, erscheint ein Fenster mit einer 3D-Visualisierung des Objekts, in dem Greifpunkte hinzugefügt oder existierende Greifpunkte bearbeitet werden können. Dasselbe Fenster erscheint, wenn ein vorhandenes Template bearbeitet wird.

Dieses Fenster bietet zwei Möglichkeiten, um Greifpunkte zu setzen:

Greifpunkte manuell hinzufügen: Durch Klicken auf das + Symbol wird ein neuer Greifpunkt im Ursprung des Templates angelegt. Diesem Greifpunkt kann ein eindeutiger Name gegeben werden, der seiner ID entspricht. Die gewünschte Pose des Greifpunkts im Koordinatensystem des Templates kann in den Feldern für Position und Roll/Pitch/Yaw eingegeben werden. Die Greifpunkte können frei platziert werden, auch außerhalb oder innerhalb des Templates, und werden mit ihrer Orientierung zur Überprüfung in der Visualisierung veranschaulicht.
Greifpunkte interaktiv hinzufügen: Greifpunkte können interaktiv zu einem Template hinzugefügt werden, indem zuerst auf den Button Greifpunkt hinzufügen oben links in der Visualisierung und anschließend auf den gewünschten Punkt auf dem Template geklickt wird. Der Greifpunkt wird an die Oberfläche angeheftet und seine Orientierung entspricht einem rechtshändigen Koordinatensystem, sodass die z-Achse senkrecht auf der Template-Oberfläche steht und in das Template hineingerichtet ist. Die Position und Orientierung des Greifpunkts im Koordinatensystem des Templates ist auf der rechten Seite angezeigt. Die Position und Orientierung des Greifpunkts kann auch interaktiv verändert werden. Für den Fall, dass An Oberfläche anheften in der Visualisierung aktiv ist (das ist der Standardwert), kann der Greifpunkt durch Klicken auf Verschieben und anschließendes Klicken auf den Greifpunkt über die Oberfläche des Templates zur gewünschten Position bewegt werden. Die Orientierung des Greifpunkts um die Oberflächennormale kann ebenfalls interaktiv verändert werden, in dem auf Rotieren geklickt wird und anschließend der Greifpunkt mit der Maus rotiert wird. Wenn An Oberfläche anheften nicht aktiv ist, kann der Greifpunkt mit der Maus frei in allen drei Raumrichtungen verschoben und rotiert werden.

Wenn das Template Symmetrien hat, können die Greifpunkte, die symmetrisch zum definierten Greifpunkt sind, durch Klick auf Symmetrische Greifpunkte anzeigen angezeigt werden.

Setzen von Greifpunkten über die REST-API¶

Greifpunkte können über die REST-API-Schnittstelle mithilfe des set_grasp oder set_all_grasps Services gesetzt werden (siehe Services). Im CADMatch-Modul besteht ein Greifpunkt aus der id, die eindeutig über alle Greifpunkte eines Objekt-Templates sein muss, der ID des Templates (template_id), zu dem der Greifpunkt hinzugefügt wird, und der Greifpose (pose) mit Position (position) in Metern und Orientierung (orientation) als Quaternion im Koordinatensystem des Templates.

Setzen der bevorzugten TCP-Orientierung¶

Das CADMatch-Modul berechnet die Erreichbarkeit von Greifpunkten basierend auf der bevorzugten Orientierung des Greifers oder TCPs. Die bevorzugte Orientierung kann über den Service set_preferred_orientation oder über die CADMatch-Seite in der Web GUI gesetzt werden. Die resultierende Richtung der z-Achse des TCP wird genutzt, um Greifpunkte zu verwerfen, die der Greifer nicht erreichen kann.

Weiterhin wird die bevorzugte Orientierung genutzt, um die erreichbaren Greifpunkte zu sortieren. Die Sortierung basiert auf einer Kombination von

der Matching Score des Objekts, auf dem sich der Greifpunkt befindet, und
dem Abstand des Greifpunkts von der Kamera entlang der z-Achse der bevorzugten TCP-Orientierung.

Die bevorzugte TCP-Orientierung kann im Kamerakoordinatensystem oder im externen Koordinatensystem gesetzt werden, wenn eine Hand-Auge-Kalibrierung verfügbar ist. Wenn die bevorzugte TCP-Orientierung im externen Koordinatensystem definiert ist, und der Sensor am Roboter montiert ist, muss bei jedem Aufruf der Objekterkennung die aktuelle Roboterpose angegeben werden, damit die bevorzugte Orientierung zur Filterung und Sortierung der Greifpunkte auf den erkannten Objekten genutzt werden kann. Wenn keine bevorzugte TCP-Orientierung gesetzt wird, wird die z-Achse der linken Kamera als die bevorzugte TCP-Orientierung genutzt.

Objekterkennung¶

Das CADMatch-Modul benötigt ein Objekt-Template für die Objekterkennung. Dieses Template enthält Informationen über die dreidimensionale Form des Objekts und markante Kanten, die im Kamerabild sichtbar sein können.

Die Objekterkennung ist ein zweistufiger Prozess bestehend aus einem initialen Schätzungsschritt und einem Posenverfeinerungsschritt. Als erstes wird die initiale Pose des Objekts anhand der Erscheinung des Objekts im Kamerabild berechnet. Als zweiter Schritt wird die geschätzte Pose anhand der 3D-Punktwolke und der Kanten im Kamerabild verfeinert. Damit das funktionieren kann, müssen die zu detektierenden Objekte im linken und rechten Kamerabild sichtbar sein.

Um eine Objekterkennung durchzuführen, müssen im Allgemeinen die folgenden Serviceargumente an das CADMatch-Modul übergeben werden:

die ID des Objekt-Templates, welches in der Szene erkannt werden soll
das Koordinatensystem, in dem die Posen der detektierten Objekte zurückgegeben werden sollen (siehe Hand-Auge-Kalibrierung)

Optional können auch folgende Serviceargumente an das CADMatch-Modul übergeben werden:

die ID des Load Carriers, der die zu detektierenden Objekte enthält
ein Unterabteil (load_carrier_compartment) innerhalb eines Behälters, in dem Objekte erkannt werden sollen (siehe ItemPick’s Berechnung der Greifpunkte)
die ID der Region of Interest, innerhalb der nach dem Load Carrier gesucht wird, oder – falls kein Load Carrier angegeben ist – die Region of Interest, innerhalb der Objekte erkannt werden sollen
die aktuelle Roboterpose, wenn die Kamera am Roboter montiert ist und als Koordinatensystem external gewählt wurde, oder die bevorzugte TCP-Orientierung im externen Koordinatensystem angegeben ist, oder die gewählte Region of Interest im externen Koordinatensystem definiert ist
Informationen für die Kollisionsprüfung: Die ID des Greifers, um die Kollisionsprüfung zu aktivieren, und optional ein Greif-Offset, der die Vorgreifposition definiert. Die Kollisionsprüfung benötigt eine gesonderte CollisionCheck-Lizenz . Details zur Kollisionsprüfung sind in CollisionCheck gegeben.

In der Web GUI kann die Objekterkennung in Bereich Ausprobieren auf der CADMatch-Seite getestet werden.

Die erkannten Objekte werden in einer Liste von matches zurückgeliefert. Jedes erkannte Objekt enthält seine uuid (Universally Unique Identifier) und den Zeitstempel (timestamp) des ältesten Bildes, das zur Erkennung benutzt wurde. Die Pose (pose) eines erkannten Objekts entspricht der Pose des Ursprungs des Koordinatensystems des Objekt-Templates, das zur Detektion verwendet wurde. Weiterhin wird ein Matching-Score zurückgegeben, der die Qualität der Erkennung angibt.

Wenn das ausgewählte Template auch Greifpunkte hat (siehe Setzen von Greifpunkten), dann wird zusätzlich zu den erkannten Objekten auch eine Liste von Greifpunkten (grasps) für alle erkannten Objekte zurückgegeben. Die Greifpunkte in dieser Liste sind nach ihrer Erreichbarkeit sortiert (siehe Setzen der bevorzugten TCP-Orientierung). Die Posen der Greifpunkte sind im gewünschten Koordinatensystem angegeben. Die erkannten Objekte und die Greifpunkte können einander über ihre UUIDs zugeordnet werden.

Bemerkung

Der erste Aufruf der Objekterkennung mit einem neuen Objekt-Template dauert etwas länger als die nachfolgenden Aufrufe, weil das Template erst in das CADMatch-Modul geladen werden muss.

Wechselwirkung mit anderen Modulen¶

Die folgenden, intern auf dem rc_visard laufenden Module liefern Daten für das CADMatch-Modul oder haben Einfluss auf die Datenverarbeitung.

Bemerkung

Jede Konfigurationsänderung dieser Module kann direkte Auswirkungen auf die Qualität oder das Leistungsverhalten des CADMatch-Moduls haben.

Stereokamera und Stereo-Matching¶

Folgende Daten werden vom CADMatch-Modul verarbeitet:

die rektifizierten Bilder des Stereokamera-Moduls (rc_stereocamera)
die Disparitäts-, Konfidenz- und Fehlerbilder des Stereo-Matching-Moduls (rc_stereomatching)

Der Parameter Qualität (quality) des Stereo-Matching-Moduls muss auf Medium oder höher gesetzt werden (siehe Parameter). Die Einstellung Full oder High wird für CADMatch empfohlen.

Für alle genutzten Bilder ist garantiert, dass diese nach dem Auslösen des Services aufgenommen wurden.

Schätzung der Gravitationsrichtung¶

Jedes Mal, wenn eine Behältererkennung oder eine Objekterkennung innerhalb eines Load Carriers durchgeführt wird, schätzt das CADMatch-Modul die Gravitationsrichtung basierend auf den IMU-Daten des rc_visard.

Bemerkung

Die Richtung des Gravitationsvektors wird durch Messungen der linearen Beschleunigung der IMU bestimmt. Für eine korrekte Schätzung des Gravitationsvektors muss der rc_visard stillstehen.

IOControl und Projektor-Kontrolle¶

Für den Anwendungsfall, dass der rc_visard zusammen mit einem externen Musterprojektor und dem Modul für IOControl und Projektor-Kontrolle (rc_iocontrol) betrieben wird, wird empfohlen, den Projektor an GPIO Out 1 anzuschließen und den Aufnahmemodus des Stereokamera-Moduls auf SingleFrameOut1 zu setzen (siehe Stereomatching-Parameter), damit bei jedem Aufnahme-Trigger ein Bild mit und ohne Projektormuster aufgenommen wird.

Alternativ kann der verwendete digitale Ausgang in den Betriebsmodus ExposureAlternateActive geschaltet werden (siehe Beschreibung der Laufzeitparameter).

In beiden Fällen sollte die Belichtungszeitregelung (exp_auto_mode) auf AdaptiveOut1 gesetzt werden, um die Belichtung beider Bilder zu optimieren (siehe Stereokamera-Parameter).

Hand-Auge-Kalibrierung¶

Falls die Kamera zu einem Roboter kalibriert wurde, kann das CADMatch-Modul automatisch Posen im Roboterkoordinatensystem ausgeben. Für die Services kann das Koordinatensystem der berechneten Posen mit dem Argument pose_frame spezifiziert werden.

Zwei verschiedene Werte für pose_frame können gewählt werden:

Kamera-Koordinatensystem (camera): Alle Posen sind im Kamera-Koordinatensystem angegeben und es ist kein zusätzliches Wissen über die Lage der Kamera in seiner Umgebung notwendig. Das bedeutet insbesondere, dass sich ROIs oder Load Carrier, welche in diesem Koordinatensystem angegeben sind, mit der Kamera bewegen. Es liegt daher in der Verantwortung des Anwenders, in solchen Fällen die entsprechenden Posen der Situation entsprechend zu aktualisieren (beispielsweise für den Anwendungsfall einer robotergeführten Kamera).
Benutzerdefiniertes externes Koordinatensystem (external): Alle Posen sind im sogenannten externen Koordinatensystem angegeben, welches vom Nutzer während der Hand-Auge-Kalibrierung gewählt wurde. In diesem Fall bezieht das CADMatch-Modul alle notwendigen Informationen über die Kameramontage und die kalibrierte Hand-Auge-Transformation automatisch vom Modul Hand-Auge-Kalibrierung. Für den Fall einer robotergeführten Kamera ist vom Nutzer zusätzlich die jeweils aktuelle Roboterpose robot_pose anzugeben.

Bemerkung

Wenn keine Hand-Auge-Kalibrierung durchgeführt wurde bzw. zur Verfügung steht, muss als Referenzkoordinatensystem pose_frame immer camera angegeben werden.

Zulässige Werte zur Angabe des Referenzkoordinatensystems sind camera und external. Andere Werte werden als ungültig zurückgewiesen.

CollisionCheck¶

Falls eine CollisionCheck-Lizenz verfügbar ist, kann die Kollisionsprüfung für die Greifpunktberechnung des CADMatch-Moduls aktiviert werden, indem die ID des benutzten Greifers und optional ein Greif-Offset an den detect_object Service übergeben werden. Der Greifer muss im CollisionCheck-Modul definiert werden (siehe Erstellen eines Greifers) und Details über die Kollisionsprüfung werden in Integrierte Kollisionsprüfung in anderen Modulen gegeben.

Wenn die Kollisionsprüfung aktiviert ist, werden nur kollisionsfreie Greifpunkte zurückgeliefert. Jedoch werden in der Ergebnis-Visualisierung oben auf der CADMatch-Seite der Web GUI kollidierende Greifpunkte als rote Punkte dargestellt.

Die Laufzeitparameter des CollisionCheck-Moduls beeinflussen die Kollisionserkennung wie in CollisionCheck-Parameter beschrieben.

Parameter¶

Das CADMatch-Modul wird in der REST-API als rc_cadmatch bezeichnet und in der Web GUI auf der Seite CADMatch (unter der Seite Module) dargestellt. Der Benutzer kann die Parameter entweder dort oder über die REST-API-Schnittstelle ändern.

Übersicht über die Parameter¶

Dieses Softwaremodul bietet folgende Laufzeitparameter:

Laufzeitparameter des `rc_cadmatch`-Moduls¶
Name	Typ	Min.	Max.	Default	Beschreibung
`edge_max_distance`	float64	0.5	5.0	2.0	Der maximale tolerierte Abstand zwischen den Templatekanten und den detektierten Kanten im Bild in Pixeln
`edge_sensitivity`	float64	0.0	1.0	0.5	Empfindlichkeit des Kantendetektors
`load_carrier_crop_distance`	float64	0.0	0.05	0.005	Sicherheitsspielraum um den das Load Carrier Innenmaß verringert wird, um eine Region of Interest für die Erkennung zu definieren
`load_carrier_model_tolerance`	float64	0.003	0.025	0.008	Gibt an, wie weit die Abmessungen des Load Carriers von den Werten im Modell abweichen dürfen
`max_matches`	int32	1	20	10	Maximale Anzahl von Matches
`min_score`	float64	0.05	1.0	0.3	Minimaler Score für Matches

Beschreibung der Laufzeitparameter¶

Die Laufzeitparameter werden zeilenweise auf der CADMatch-Seite in der Web GUI dargestellt. Im folgenden wird der Name des Parameters in der Web GUI in Klammern hinter dem eigentlichen Parameternamen angegeben. Die Parameter sind in derselben Reihenfolge wie in der Web GUI aufgelistet:

max_matches (Maximale Matches): ist die maximale Anzahl der zu erkennenden Objekte.
min_score (Minimaler Score): ist der minimale Score für die Erkennung nach der Posenverfeinerung. Umso höher dieser Wert ist, umso besser müssen die 2D-Kanten und die 3D-Punktwolke mit dem angegebenen Template übereinstimmen.
load_carrier_model_tolerance (Modelltoleranz): siehe Parameter der Load Carrier Funktionalität.
load_carrier_crop_distance (Cropping): siehe Parameter der Load Carrier Funktionalität.
edge_sensitivity (Kantenempfindlichkeit): ist die Empfindlichkeit des Kantendetektors. Umso höher dieser Wert ist, umso mehr Kanten werden für die Posenverfeinerung genutzt.
edge_max_distance (Maximale Kantendistanz): ist die maximal erlaubte Distanz in Pixeln zwischen den Templatekanten und den detektierten Kanten im Bild während der Posenverfeinerung.

Statuswerte¶

Das CADMatch-Modul meldet folgende Statuswerte.

Statuswerte des `rc_cadmatch`-Moduls¶
Name	Beschreibung
`data_acquisition_time`	Zeit in Sekunden, für die beim letzten Aufruf auf Bilddaten gewartet werden musste
`last_timestamp_processed`	Zeitstempel des letzten verarbeiteten Bilddatensatzes
`load_carrier_detection_time`	Berechnungszeit für die letzte Load Carrier Detektion in Sekunden
`object_detection_time`	Berechnungszeit für die letzte Objekterkennung in Sekunden
`state`	Aktueller Zustand des CADMatch-Moduls

Folgende state-Werte werden gemeldet.

Mögliche Werte für den Zustand des CADMatch-Moduls¶
Zustand	Beschreibung
IDLE	Das Modul ist inaktiv.
RUNNING	Das Modul wurde gestartet und ist bereit, Behälter und Objekte zu erkennen.
FATAL	Ein schwerwiegender Fehler ist aufgetreten.

Services¶

Die angebotenen Services von rc_cadmatch können mithilfe der REST-API-Schnittstelle oder der rc_visard Web GUI ausprobiert und getestet werden.

Zusätzlich zur eigentlichen Serviceantwort gibt jeder Service einen sogenannten return_code bestehend aus einem Integer-Wert und einer optionalen Textnachricht zurück. Erfolgreiche Service-Anfragen werden mit einem Wert von 0 quittiert. Positive Werte bedeuten, dass die Service-Anfrage zwar erfolgreich bearbeitet wurde, aber zusätzliche Informationen zur Verfügung stehen. Negative Werte bedeuten, dass Fehler aufgetreten sind. Für den Fall, dass mehrere Rückgabewerte zutreffend wären, wird der kleinste zurückgegeben, und die entsprechenden Textnachrichten werden in return_code.message akkumuliert.

Die folgende Tabelle führt die möglichen Rückgabe-Codes an:

Rückgabecodes der Services des CADMatch-Moduls¶
Code	Beschreibung
0	Erfolgreich
-1	Ungültige(s) Argument(e)
-2	Ein interner Fehler ist aufgetreten.
-3	Ein interner Timeout ist aufgetreten, beispielsweise während der Objekterkennung.
-4	Die maximal erlaubte Zeitspanne von 5.0 Sekunden für die interne Akquise der Bilddaten wurde überschritten.
-8	Das Modul befindet sich in einem Zustand, in welchem dieser Service nicht aufgerufen werden kann. Beispielsweise muss die Stereo-Matching Qualität `quality` mindestens `Medium` sein.
-9	Ungültige Lizenz
-10	Das neue Element konnte nicht hinzugefügt werden, da die maximal speicherbare Anzahl an Load Carriern oder ROIs überschritten wurde.
10	Die maximal speicherbare Anzahl an Load Carriern oder ROIs wurde erreicht.
11	Existierende Daten wurden überschrieben.
100	Die angefragten Load Carrier wurden in der Szene nicht gefunden.
101	Keiner der gefundenen Greifpunkte ist erreichbar.
102	Der erkannte Load Carrier ist leer.
103	Alle berechneten Greifpunkte sind in Kollision mit dem Load Carrier.
151	Das Objekt-Template hat eine kontinuierliche Symmetrie.
999	Zusätzliche Hinweise für die Anwendungsentwicklung

Das CADMatch-Modul stellt folgende Services zur Verfügung.

`start`¶

versetzt das CADMatch-Modul in den Zustand RUNNING. Es kann vorkommen, dass der Zustandsübergang noch nicht vollständig abgeschlossen ist, wenn die Serviceantwort generiert wird. In diesem Fall liefert diese den entsprechenden, sich von RUNNING unterscheidenden Zustand zurück.

Dieser Service hat keine Argumente.

Die Definition der Response mit jeweiligen Datentypen ist:
{
  "accepted": "bool",
  "current_state": "string"
}

`stop`¶

stoppt das Modul und versetzt es in den Zustand IDLE. Es kann vorkommen, dass der Zustandsübergang noch nicht vollständig abgeschlossen ist, wenn die Serviceantwort generiert wird. In diesem Fall liefert diese den entsprechenden, sich von IDLE unterscheidenden Zustand zurück.

Dieser Service hat keine Argumente.

Die Definition der Response mit jeweiligen Datentypen ist:
{
  "accepted": "bool",
  "current_state": "string"
}

`set_region_of_interest`¶

siehe set_region_of_interest.

`get_regions_of_interest`¶

siehe get_regions_of_interest.

`delete_regions_of_interest`¶

siehe delete_regions_of_interest.

`set_load_carrier`¶

siehe set_load_carrier.

`get_load_carriers`¶

siehe get_load_carriers.

`delete_load_carriers`¶

siehe delete_load_carriers.

`detect_load_carriers`¶

siehe detect_load_carriers.

`detect_filling_level`¶

siehe detect_filling_level.

`set_preferred_orientation`¶

speichert die bevorzugte TCP-Orientierung zum Berechnen der Erreichbarkeit der Greifpunkte, die zur Sortierung und Filterung der vom detect_object Service zurückgelieferten Greifpunkte verwendet wird (siehe Setzen der bevorzugten TCP-Orientierung).

Die Definition der Request-Argumente mit jeweiligen Datentypen ist:
{
  "orientation": {
    "w": "float64",
    "x": "float64",
    "y": "float64",
    "z": "float64"
  },
  "pose_frame": "string"
}
Die Definition der Response mit jeweiligen Datentypen ist:
{
  "return_code": {
    "message": "string",
    "value": "int16"
  }
}

`get_preferred_orientation`¶

gibt die bevorzugte TCP-Orientierung zurück, die für die Sortierung und Filterung der vom detect_object Service zurückgelieferten Greifpunkte verwendet wird (siehe Setzen der bevorzugten TCP-Orientierung).

Dieser Service hat keine Argumente.

Die Definition der Response mit jeweiligen Datentypen ist:
{
  "orientation": {
    "w": "float64",
    "x": "float64",
    "y": "float64",
    "z": "float64"
  },
  "pose_frame": "string",
  "return_code": {
    "message": "string",
    "value": "int16"
  }
}

`set_grasp`¶

speichert einen Greifpunkt für das angegebene Template auf dem rc_visard. Alle Greifpunkte sind dauerhaft gespeichert, auch über Firmware-Updates und -Wiederherstellungen hinweg.

Die Definition der Request-Argumente mit jeweiligen Datentypen ist:
{
  "grasp": {
    "id": "string",
    "pose": {
      "orientation": {
        "w": "float64",
        "x": "float64",
        "y": "float64",
        "z": "float64"
      },
      "position": {
        "x": "float64",
        "y": "float64",
        "z": "float64"
      }
    },
    "template_id": "string"
  }
}
Die Definition der Response mit jeweiligen Datentypen ist:
{
  "return_code": {
    "message": "string",
    "value": "int16"
  }
}
Die Definition des Typs grasp wird in Setzen von Greifpunkten beschrieben.

`set_all_grasps`¶

Ersetzt die gesamte Liste von Greifpunkten auf dem rc_visard für das angegebene Template.

Die Definition der Request-Argumente mit jeweiligen Datentypen ist:

{
  "grasps": [
    {
      "id": "string",
      "pose": {
        "orientation": {
          "w": "float64",
          "x": "float64",
          "y": "float64",
          "z": "float64"
        },
        "position": {
          "x": "float64",
          "y": "float64",
          "z": "float64"
        }
      },
      "template_id": "string"
    }
  ],
  "template_id": "string"
}

Die Definition der Response mit jeweiligen Datentypen ist:

{
  "return_code": {
    "message": "string",
    "value": "int16"
  }
}

Die Definition des Typs grasp wird in Setzen von Greifpunkten beschrieben.

`get_grasps`¶

gibt alle definierten Greifpunkte mit den angegebenen IDs (grasp_ids) zurück, die zu den Templates mit den angegebenen template_ids gehören. Wenn keine grasp_ids angegeben werden, werden alle Greifpunkte zu den angegebenen template_ids zurückgeliefert. Wenn keine template_ids angegeben werden, werden alle Greifpunkte mit den geforderten grasp_ids zurückgeliefert. Wenn gar keine IDs angegeben werden, werden alle gespeicherten Greifpunkte zurückgeliefert.

Die Definition der Request-Argumente mit jeweiligen Datentypen ist:
{
  "grasp_ids": [
    "string"
  ],
  "template_ids": [
    "string"
  ]
}
Die Definition der Response mit jeweiligen Datentypen ist:
{
  "grasps": [
    {
      "id": "string",
      "pose": {
        "orientation": {
          "w": "float64",
          "x": "float64",
          "y": "float64",
          "z": "float64"
        },
        "position": {
          "x": "float64",
          "y": "float64",
          "z": "float64"
        }
      },
      "template_id": "string"
    }
  ],
  "return_code": {
    "message": "string",
    "value": "int16"
  }
}

`delete_grasps`¶

löscht alle Greifpunkte mit den angegebenen grasp_ids, die zu den Templates mit den angegebenen template_ids gehören. Wenn keine grasp_ids angegeben werden, werden alle Greifpunkte gelöscht, die zu den Templates mit den angegebenen template_ids gehören. Die Liste template_ids darf nicht leer sein.

Die Definition der Request-Argumente mit jeweiligen Datentypen ist:
{
  "grasp_ids": [
    "string"
  ],
  "template_ids": [
    "string"
  ]
}
Die Definition der Response mit jeweiligen Datentypen ist:
{
  "return_code": {
    "message": "string",
    "value": "int16"
  }
}

`get_symmetric_grasps`¶

gibt alle Greifpunkte zurück, die symmetrisch zum angegebenen Greifpunkt sind. Der erste Greifpunkt in der Rückgabeliste ist derselbe, der dem Service übergeben wurde. Wenn das Template keine exakte Symmetrie hat, wird nur der übergebene Greifpunkt zurückgeliefert. Wenn das Template eine kontinuierliche Symmetrie hat (z.B. ein zylindrisches Objekt), werden nur 12 gleichverteilte Greifpunkte zurückgeliefert.

Die Definition der Request-Argumente mit jeweiligen Datentypen ist:

{
  "grasp": {
    "id": "string",
    "pose": {
      "orientation": {
        "w": "float64",
        "x": "float64",
        "y": "float64",
        "z": "float64"
      },
      "position": {
        "x": "float64",
        "y": "float64",
        "z": "float64"
      }
    },
    "template_id": "string"
  }
}

Die Definition der Response mit jeweiligen Datentypen ist:

{
  "grasps": [
    {
      "id": "string",
      "pose": {
        "orientation": {
          "w": "float64",
          "x": "float64",
          "y": "float64",
          "z": "float64"
        },
        "position": {
          "x": "float64",
          "y": "float64",
          "z": "float64"
        }
      },
      "template_id": "string"
    }
  ],
  "return_code": {
    "message": "string",
    "value": "int16"
  }
}

Die Definition des Typs grasp wird in Setzen von Greifpunkten beschrieben.

`detect_object`¶

führt eine Objekterkennung basierend auf einem Template durch, wie in Objekterkennung beschrieben.

Request:

Die Definition der Request-Argumente mit jeweiligen Datentypen ist:
{
  "collision_detection": {
    "gripper_id": "string",
    "pre_grasp_offset": {
      "x": "float64",
      "y": "float64",
      "z": "float64"
    }
  },
  "load_carrier_compartment": {
    "box": {
      "x": "float64",
      "y": "float64",
      "z": "float64"
    },
    "pose": {
      "orientation": {
        "w": "float64",
        "x": "float64",
        "y": "float64",
        "z": "float64"
      },
      "position": {
        "x": "float64",
        "y": "float64",
        "z": "float64"
      }
    }
  },
  "load_carrier_id": "string",
  "pose_frame": "string",
  "region_of_interest_id": "string",
  "robot_pose": {
    "orientation": {
      "w": "float64",
      "x": "float64",
      "y": "float64",
      "z": "float64"
    },
    "position": {
      "x": "float64",
      "y": "float64",
      "z": "float64"
    }
  },
  "template_id": "string"
}
Obligatorische Serviceargumente:

pose_frame: siehe Hand-Auge-Kalibrierung.

template_id: ID des Templates, welches erkannt werden soll.

Möglicherweise benötigte Serviceargumente:

robot_pose: see Hand-Auge-Kalibrierung.

Optionale Serviceargumente:

load_carrier_id: ID des Load Carriers, welcher die zu erkennenden Objekte enthält.

load_carrier_compartment: Teilvolumen (Fach oder Abteil) in einem zu detektierenden Load Carrier (Behälter), in dem Objekte erkannt werden sollen.

region_of_interest_id: Falls load_carrier_id gesetzt ist, die ID der Region of Interest, innerhalb welcher nach dem Load Carrier gesucht wird. Andernfalls die ID der Region of Interest, in der nach Objekten gesucht wird.

collision_detection: siehe Integrierte Kollisionsprüfung in anderen Modulen. Die Kollisionsprüfung benötigt eine gesonderte CollisionCheck-Lizenz.

Response:

Die Definition der Response mit jeweiligen Datentypen ist:

{
  "grasps": [
    {
      "id": "string",
      "match_uuid": "string",
      "pose": {
        "orientation": {
          "w": "float64",
          "x": "float64",
          "y": "float64",
          "z": "float64"
        },
        "position": {
          "x": "float64",
          "y": "float64",
          "z": "float64"
        }
      },
      "pose_frame": "string",
      "timestamp": {
        "nsec": "int32",
        "sec": "int32"
      },
      "uuid": "string"
    }
  ],
  "load_carriers": [
    {
      "id": "string",
      "inner_dimensions": {
        "x": "float64",
        "y": "float64",
        "z": "float64"
      },
      "outer_dimensions": {
        "x": "float64",
        "y": "float64",
        "z": "float64"
      },
      "overfilled": "bool",
      "pose": {
        "orientation": {
          "w": "float64",
          "x": "float64",
          "y": "float64",
          "z": "float64"
        },
        "position": {
          "x": "float64",
          "y": "float64",
          "z": "float64"
        }
      },
      "pose_frame": "string",
      "rim_thickness": {
        "x": "float64",
        "y": "float64"
      }
    }
  ],
  "matches": [
    {
      "grasp_uuids": [
        "string"
      ],
      "pose": {
        "orientation": {
          "w": "float64",
          "x": "float64",
          "y": "float64",
          "z": "float64"
        },
        "position": {
          "x": "float64",
          "y": "float64",
          "z": "float64"
        }
      },
      "pose_frame": "string",
      "score": "float32",
      "template_id": "string",
      "timestamp": {
        "nsec": "int32",
        "sec": "int32"
      },
      "uuid": "string"
    }
  ],
  "return_code": {
    "message": "string",
    "value": "int16"
  },
  "timestamp": {
    "nsec": "int32",
    "sec": "int32"
  }
}

grasps: Liste von Greifpunkten auf den erkannten Objekten. Die Greifpunkte sind nach ihrer Erreichbarkeit sortiert, begonnen mit dem Greifpunkt, der am besten vom Roboter erreicht werden kann. Die match_uuid gibt eine Referenz auf das detektierte Objekt in matches an, zu dem dieser Greifpunkt gehört.

load_carriers: Liste der erkannten Load Carrier (Behälter).

matches: Liste der erkannten Objekte für das angegebene Template. Der score gibt an, wie gut das Objekt mit dem Template übereinstimmt. Die grasp_uuids geben die Greifpunkte in der grasps-Liste an, die auf diesem Objekt erreichbar sind.

timestamp: Zeitstempel des Bildes, auf dem die Erkennung durchgeführt wurde.

return_code: enthält mögliche Warnungen oder Fehlercodes und Nachrichten.

`save_parameters`¶

Beim Aufruf dieses Services werden die aktuellen Parametereinstellungen des CADMatch-Moduls auf dem rc_visard gespeichert. Das bedeutet, dass diese Werte selbst nach einem Neustart angewandt werden. Bei Firmware-Updates oder -Wiederherstellungen werden sie jedoch wieder auf den Standardwert gesetzt.

Dieser Service hat keine Argumente.

Die Definition der Response mit jeweiligen Datentypen ist:
{
  "return_code": {
    "message": "string",
    "value": "int16"
  }
}

`reset_defaults`¶

Hiermit werden die Werkseinstellungen der Parameter dieses Moduls wiederhergestellt und angewandt („factory reset“). Dies betrifft nicht die konfigurierten ROIs und Load Carrier.

Dieser Service hat keine Argumente.

Die Definition der Response mit jeweiligen Datentypen ist:
{
  "return_code": {
    "message": "string",
    "value": "int16"
  }
}

Template Upload¶

Für den Upload, Download und das Auflisten von Templates werden spezielle REST-API-Endpunkte zur Verfügung gestellt. Bis zu 30 Templates können gleichzeitig auf dem rc_visard gespeichert werden.

CADMatch¶

Einleitung¶

Setzen von Greifpunkten¶

Setzen von Greifpunken in der Web GUI¶

Setzen von Greifpunkten über die REST-API¶

Setzen der bevorzugten TCP-Orientierung¶

Objekterkennung¶

Wechselwirkung mit anderen Modulen¶

Stereokamera und Stereo-Matching¶

Schätzung der Gravitationsrichtung¶

IOControl und Projektor-Kontrolle¶

Hand-Auge-Kalibrierung¶

CollisionCheck¶

Parameter¶

Übersicht über die Parameter¶

Beschreibung der Laufzeitparameter¶

Statuswerte¶

Services¶

start¶

stop¶

set_region_of_interest¶

get_regions_of_interest¶

delete_regions_of_interest¶

set_load_carrier¶

get_load_carriers¶

delete_load_carriers¶

detect_load_carriers¶

detect_filling_level¶

set_preferred_orientation¶

get_preferred_orientation¶

set_grasp¶

set_all_grasps¶

get_grasps¶

delete_grasps¶

get_symmetric_grasps¶

detect_object¶

save_parameters¶

reset_defaults¶

Template Upload¶

`start`¶

`stop`¶

`set_region_of_interest`¶

`get_regions_of_interest`¶

`delete_regions_of_interest`¶

`set_load_carrier`¶

`get_load_carriers`¶

`delete_load_carriers`¶

`detect_load_carriers`¶

`detect_filling_level`¶

`set_preferred_orientation`¶

`get_preferred_orientation`¶

`set_grasp`¶

`set_all_grasps`¶

`get_grasps`¶

`delete_grasps`¶

`get_symmetric_grasps`¶

`detect_object`¶

`save_parameters`¶

`reset_defaults`¶