CollisionCheck¶

Einleitung¶

Das CollisionCheck-Modul ist optional und läuft intern auf dem rc_cube.

Bemerkung

Das Modul ist optional und benötigt eine separate Lizenz .

Das Modul ermöglicht die Kollisionsprüfung zwischen dem Greifer und dem Load Carrier. Es ist in die Module ItemPick und BoxPick, SilhouetteMatch und CADMatch integriert, kann aber auch als eigenständiges Modul genutzt werden.

Warnung

Es werden nur Kollisionen zwischen dem Load Carrier und dem Greifer geprüft, aber nicht Kollisionen mit dem Roboter, dem Flansch, anderen Objekten oder dem Objekt im Greifer.

Erstellen eines Greifers¶

Der Greifer ist eine Kollisionsgeometrie, die zur Prüfung auf Kollisionen zwischen dem geplanten Griff und dem Load Carrier verwendet wird. Der Greifer kann aus bis zu 15 miteinander verbundenen Elementen bestehen.

Es sind folgende Arten von Elementen möglich:

Quader (BOX), mit den Abmessungen box.x, box.y, box.z.

Zylinder (CYLINDER), mit dem Radius cylinder.radius und der Höhe cylinder.height.

Weiterhin müssen für jeden Greifer der Flanschradius und der Tool Center Point (TCP) definiert werden.

Die Konfiguration des Greifers wird in der Regel während des Setups der Zielanwendung durchgeführt. Das kann über die REST-API-Schnittstelle oder die rc_cube Web GUI geschehen.

Flanschradius¶

Es werden standardmäßig nur Kollisionen zwischen dem Greifer und dem Load Carrier geprüft. Die Robotergeometrie wird nicht berücksichtigt. Um Kollisionen zwischen dem Load Carrier und dem Roboter zu vermeiden, kann über den Laufzeitparameter check_flange (siehe Übersicht der Parameter) ein zusätzlicher optionaler Test aktiviert werden. Dieser Test erkennt alle Griffe als Kollisionen, bei denen sich ein Teil des Roboterflanschs innerhalb des Load Carriers befinden würde (siehe Abb. 33). Der Test basiert auf der Greifergeometrie und dem Flanschradius.

Abb. 33 Fall A: Der Griff wird nur als Kollision erkannt, wenn check_flange auf true gesetzt ist, denn der Flansch (rot) befindet sich im Load Carrier. Fall B: Der Griff ist in jedem Fall kollisionsfrei.

Erstellen eines Greifers über die REST-API¶

Bei der Greifererstellung über die REST-API-Schnittstelle hat jedes Greifer-Element ein Parent-Element, das die Verbindung zwischen den Elementen definiert. Der Greifer wird immer vom Roboterflansch ausgehend in Richtung TCP aufgebaut, und mindestens ein Element muss den Parent ‚flange‘ (Flansch) haben. Die IDs der Elemente müssen eindeutig sein und dürfen nicht ‚tcp‘ oder ‚flange‘ sein. Die Pose des Elements muss im Koordinatensystem des Parent-Elements angegeben werden. In der REST-API-Repräsentation ist das Koordinatensystem jedes Elements genau in seinem geometrischen Mittelpunkt. Damit ein Element also genau unterhalb seines Parent-Elements platziert wird, muss seine Position aus der Höhe des Parent-Elements und seiner eigenen Höhe berechnet werden (siehe Abb. 34).

Abb. 34 Bezugskoordinatensysteme für das Erstellen von Greifern über die REST-API

Das Bezugskoordinatensystem für das erste Element liegt immer im Mittelpunkt des Roboterflanschs, wobei die z-Achse nach unten gerichtet ist. Über die REST-API können Greifer mit einer Baumstruktur erstellt werden, bei denen mehrere Elemente dasselbe Parent-Element haben.

Erstellen eines Greifers in der Web GUI¶

Die CollisionCheck-Seite in der rc_cube Web GUI bietet ein vereinfachtes Interface zum Erstellen von Greifern. Es ermöglicht die Auswahl des Typs, der Größe und der Position jedes Greiferelements. In der Web GUI-Repräsentation bezieht sich die Position jedes Elements auf die Unterseite des darüber liegenden Parent-Elements. Ein Element mit der Position (0, 0, 0) wird also genau unterhalb seines Parent-Elements platziert. Greifer mit einer Baumstruktur oder mit rotierten Elementen können nicht über die Web GUI erstellt werden.

Berechnete TCP-Position¶

Nach dem Erstellen des Greifers mit dem Service set_gripper, wird die TCP-Position im Flanschkoordinatensystem berechnet und als tcp_pose_flange zurückgegeben. Dieser Wert muss mit den tatsächlichen TCP-Koordinaten des Roboters übereinstimmen.

Nicht-rotationssymmetrische Greifer erstellen¶

Bei Greifern, die nicht rotationssymmetrisch um die z-Achse sind, muss sichergestellt werden, dass der Greifer so montiert wird, dass seine Ausrichtung mit der im CollisionCheck-Modul gespeicherten Darstellung übereinstimmt.

Kollisionsprüfung¶

Stand-Alone Kollisionsprüfung¶

Der Service check_collision triggert die Kollisionsprüfung zwischen dem angegebenen Greifer und dem angegebenen Load Carrier für jeden der übergebenen Greifpunkte. Das CollisionCheck-Modul überprüft, ob sich der Greifer in Kollision mit mindestens einem Load Carrier befindet, wenn sich der TCP an der Greifposition befindet. Es können mehrere Load Carrier gleichzeitig getestet werden. Der Griff wird als Kollision markiert, wenn es mit mindestens einem der definierten Load Carriern zu einer Kollision kommen würde.

Das Argument pre_grasp_offset (Greif-Offset) kann für eine erweiterte Kollisionsprüfung genutzt werden. Der Greif-Offset \(P_{off}\) ist der Offset vom Greifpunkt \(P_{grasp}\) zur Vorgreifposition \(P_{pre}\) im Koordinatensystem des Greifpunkts (siehe Abb. 35). Wenn der Greif-Offset angegeben wird, werden Greifpunkte auch dann als Kollisionen erkannt, wenn der Greifer an einem beliebigen Punkt während der linearen Bewegung zwischen Vorgreifposition und Greifposition in Kollision mit dem Load Carrier geraten würde.

Abb. 35 Darstellung des Greif-Offsets für die Kollisionsprüfung. Im dargestellten Fall sind sowohl die Vorgreifposition als auch die Greifposition kollisionsfrei, aber die Trajektorie zwischen diesen Punkten hätte eine Kollision mit dem Load Carrier. Deswegen wird dieser Greifpunkt als Kollision erkannt.

Integrierte Kollisionsprüfung in anderen Modulen¶

Die Kollisionsprüfung ist in die Services der folgenden Softwaremodule integriert:

ItemPick und BoxPick: compute_grasps (siehe compute_grasps für ItemPick und compute_grasps für BoxPick)
SilhouetteMatch: detect_object (siehe detect_object)
CADMatch: detect_object (siehe detect_object)

Jedem dieser Services kann ein collision_detection-Argument übergeben werden, das aus der ID des Greifers (gripper_id) und optional aus dem Greif-Offset (pre_grasp_offset, siehe Stand-Alone Kollisionsprüfung) besteht. Wenn das collision_detection Argument übergeben wird, liefern diese Services nur die Greifpunkte zurück, an denen der Greifer nicht in Kollision mit dem erkannten Load Carrier ist. Dazu muss dem jeweiligen Service auch die ID des zu erkennenden Load Carriers übergeben werden.

Warnung

Es werden nur Kollisionen zwischen dem Load Carrier und dem Greifer geprüft, aber nicht Kollisionen mit dem Roboter, dem Flansch, anderen Objekten oder dem Objekt im Greifer.

Die Kollisionsprüfung wird von Laufzeitparametern beeinflusst, die weiter unten aufgeführt und beschrieben werden.

Parameter¶

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

Übersicht der Parameter¶

Dieses Softwaremodul bietet folgende Laufzeitparameter:

Tab. 35 Applikationsspezifische Laufzeitparameter des `rc_collision_check` Moduls¶
Name	Typ	Min	Max	Default	Beschreibung
`check_bottom`	bool	false	true	true	Kollisionsprüfung mit dem Boden des Load Carriers.
`check_flange`	bool	false	false	true	Die Position ist in Kollision, wenn der Flansch innerhalb des Load Carriers ist.
`collision_dist`	float64	0.0	0.1	0.01	Minimaler Abstand in Metern zwischen einem Greiferelement und den Wänden des Load Carriers für einen kollisionsfreien Griff.

Beschreibung der Laufzeitparameter¶

Jeder Laufzeitparameter ist durch eine eigene Zeile auf der Seite des CollisionCheck-Moduls der Web GUI repräsentiert. Der Web GUI-Name des Parameters ist in Klammern hinter dem Namen des Parameters angegeben:

collision_dist (Sicherheitsabstand): Minimaler Abstand zwischen einem Greiferelement und den Wänden des Load Carriers für einen kollisionsfreien Griff.
check_flange (Flansch-Check): Ermöglicht einen Sicherheitscheck mit dem Flansch, wie in Flanschradius beschrieben. Wenn dieser Parameter gesetzt ist, gelten alle Griffe, bei denen der Flansch innerhalb des Load Carriers wäre, als Kollisionen.
check_bottom (Boden-Check): Wenn dieser Check aktiviert ist, werden Kollisionen nicht nur mit den Load Carrier Wänden, sondern auch mit dem Boden geprüft. Falls der TCP innerhalb der Kollisionsgeometrie (z.B. innerhalb des Sauggreifers) liegt, ist es möglicherweise nötig, diesen Check zu deaktivieren.

Statuswerte¶

Statuswerte des rc_collision_check-Moduls:

Tab. 36 Statuswerte des `rc_collision_check`-Moduls¶
Name	Beschreibung
`last_evaluated_grasps`	Anzahl der ausgewerteten Griffe
`last_collision_free_grasps`	Anzahl der kollisionsfreien Griffe

Services¶

Die angebotenen Services von rc_collision_check können mithilfe der REST-API-Schnittstelle oder der rc_cube 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:

Tab. 37 Fehlercodes des CollisionCheck-Services¶
Code	Beschreibung
0	Erfolgreich
-1	Ein ungültiges Argument wurde übergeben.
-7	Daten konnten nicht in den persistenten Speicher geschrieben oder vom persistenten Speicher gelesen werden.
-9	Lizenz für CollisionCheck ist nicht verfügbar.
-10	Das neue Element konnte nicht hinzugefügt werden, da die maximal speicherbare Anzahl an Greifern überschritten wurde.
10	Die maximal speicherbare Anzahl an Greifern wurde erreicht.
11	Bestehender Greifer wurde überschrieben.

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

`set_gripper`¶

konfiguriert und speichert einen Greifer auf dem rc_cube. Alle Greifer sind dauerhaft gespeichert, auch über Firmware-Updates und -Wiederherstellungen hinweg.

Request:

Die Definition der Request-Argumente mit jeweiligen Datentypen ist:
{
  "elements": [
    {
      "box": {
        "x": "float64",
        "y": "float64",
        "z": "float64"
      },
      "cylinder": {
        "height": "float64",
        "radius": "float64"
      },
      "id": "string",
      "parent_id": "string",
      "pose": {
        "orientation": {
          "w": "float64",
          "x": "float64",
          "y": "float64",
          "z": "float64"
        },
        "position": {
          "x": "float64",
          "y": "float64",
          "z": "float64"
        }
      },
      "type": "string"
    }
  ],
  "flange_radius": "float64",
  "id": "string",
  "tcp_parent_id": "string",
  "tcp_pose_parent": {
    "orientation": {
      "w": "float64",
      "x": "float64",
      "y": "float64",
      "z": "float64"
    },
    "position": {
      "x": "float64",
      "y": "float64",
      "z": "float64"
    }
  }
}
Obligatorische Serviceargumente:

elements: Liste von geometrischen Elementen, aus denen der Greifer besteht. Jedes Element muss den type ‚CYLINDER‘ oder ‚BOX‘ haben, wobei die Dimensionen im Feld cylinder bzw. box angegeben werden. Die Pose jedes Elements muss im Parent-Koordinatensystem angegeben werden (siehe Erstellen eines Greifers). Die id des Elements muss eindeutig sein und darf nicht ‚tcp‘ oder ‚flange‘ sein. Die parent_id ist die ID des Parent-Elements, welche entweder ‚flange‘ ist oder der ID eines anderen Elements entsprechen muss.

flange_radius: Flanschradius der benutzt wird, falls der Parameter check_flange aktiviert ist.

id: Eindeutiger Name des Greifers.

tcp_parent_id: ID des Elements, auf dem der TCP definiert ist.

tcp_pose_parent: Die Pose des TCP im Koordinatensystem des Elements, das in tcp_parent_id angegeben ist.

Response:

Die Definition der Response mit jeweiligen Datentypen ist:

{
  "gripper": {
    "elements": [
      {
        "box": {
          "x": "float64",
          "y": "float64",
          "z": "float64"
        },
        "cylinder": {
          "height": "float64",
          "radius": "float64"
        },
        "id": "string",
        "parent_id": "string",
        "pose": {
          "orientation": {
            "w": "float64",
            "x": "float64",
            "y": "float64",
            "z": "float64"
          },
          "position": {
            "x": "float64",
            "y": "float64",
            "z": "float64"
          }
        },
        "type": "string"
      }
    ],
    "flange_radius": "float64",
    "id": "string",
    "tcp_parent_id": "string",
    "tcp_pose_flange": {
      "orientation": {
        "w": "float64",
        "x": "float64",
        "y": "float64",
        "z": "float64"
      },
      "position": {
        "x": "float64",
        "y": "float64",
        "z": "float64"
      }
    },
    "tcp_pose_parent": {
      "orientation": {
        "w": "float64",
        "x": "float64",
        "y": "float64",
        "z": "float64"
      },
      "position": {
        "x": "float64",
        "y": "float64",
        "z": "float64"
      }
    },
    "type": "string"
  },
  "return_code": {
    "message": "string",
    "value": "int16"
  }
}

gripper: Gibt den Greifer mit dem zusätzlichen Feld tcp_pose_flange zurück. Dieses Feld gibt die TCP-Koordinaten im Flanschkoordinatensystem an, um diese mit den Roboter-TCP-Koordinaten vergleichen zu können.

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

`get_grippers`¶

gibt die mit gripper_ids spezifizierten und gespeicherten Greifer zurück. Wenn keine gripper_ids angegeben werden, enthält die Serviceantwort alle gespeicherten Greifer.

Die Definition der Request-Argumente mit jeweiligen Datentypen ist:

{
  "gripper_ids": [
    "string"
  ]
}

Die Definition der Response mit jeweiligen Datentypen ist:

{
  "grippers": [
    {
      "elements": [
        {
          "box": {
            "x": "float64",
            "y": "float64",
            "z": "float64"
          },
          "cylinder": {
            "height": "float64",
            "radius": "float64"
          },
          "id": "string",
          "parent_id": "string",
          "pose": {
            "orientation": {
              "w": "float64",
              "x": "float64",
              "y": "float64",
              "z": "float64"
            },
            "position": {
              "x": "float64",
              "y": "float64",
              "z": "float64"
            }
          },
          "type": "string"
        }
      ],
      "flange_radius": "float64",
      "id": "string",
      "tcp_parent_id": "string",
      "tcp_pose_flange": {
        "orientation": {
          "w": "float64",
          "x": "float64",
          "y": "float64",
          "z": "float64"
        },
        "position": {
          "x": "float64",
          "y": "float64",
          "z": "float64"
        }
      },
      "tcp_pose_parent": {
        "orientation": {
          "w": "float64",
          "x": "float64",
          "y": "float64",
          "z": "float64"
        },
        "position": {
          "x": "float64",
          "y": "float64",
          "z": "float64"
        }
      },
      "type": "string"
    }
  ],
  "return_code": {
    "message": "string",
    "value": "int16"
  }
}

`delete_grippers`¶

löscht die mit gripper_ids spezifizierten, gespeicherten Greifer. Alle zu löschenden Greifer müssen explizit angegeben werden.

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

`check_collision`¶

löst eine Kollisionsprüfung aus.

Request:

Die Definition der Request-Argumente mit jeweiligen Datentypen ist:

{
  "grasps": [
    {
      "pose": {
        "orientation": {
          "w": "float64",
          "x": "float64",
          "y": "float64",
          "z": "float64"
        },
        "position": {
          "x": "float64",
          "y": "float64",
          "z": "float64"
        }
      },
      "pose_frame": "string",
      "uuid": "string"
    }
  ],
  "gripper_id": "string",
  "load_carriers": [
    {
      "id": "string",
      "inner_dimensions": {
        "x": "float64",
        "y": "float64",
        "z": "float64"
      },
      "outer_dimensions": {
        "x": "float64",
        "y": "float64",
        "z": "float64"
      },
      "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"
      }
    }
  ],
  "pre_grasp_offset": {
    "x": "float64",
    "y": "float64",
    "z": "float64"
  }
}

Obligatorische Serviceargumente:

grasps: Liste von Griffen, die überprüft werden sollen.

load_carriers: Liste von Load Carriern, die auf Kollisionen überprüft werden sollen. Die Felder der Load Carrier Definition sind in Erkennung von Load Carriern beschrieben. Die Griffe und die Load Carrier Positionen müssen im selben Koordinatensystem angegeben werden.

gripper_id: Die ID des Greifers, der in der Kollisionsprüfung verwendet werden soll. Der Greifer muss zuvor konfiguriert worden sein.

Optionale Serviceargumente:

pre_grasp_offset: Der Greif-Offset in Metern vom Greifpunkt zur Vorgreifposition. Wird ein Greif-Offset angegeben, dann wird die Kollisionsprüfung auf der gesamten linearen Trajektorie von der Vorgreifposition bis zur Greifposition durchgeführt.

Response:

Die Definition der Response mit jeweiligen Datentypen ist:

{
  "colliding_grasps": [
    {
      "pose": {
        "orientation": {
          "w": "float64",
          "x": "float64",
          "y": "float64",
          "z": "float64"
        },
        "position": {
          "x": "float64",
          "y": "float64",
          "z": "float64"
        }
      },
      "pose_frame": "string",
      "uuid": "string"
    }
  ],
  "collision_free_grasps": [
    {
      "pose": {
        "orientation": {
          "w": "float64",
          "x": "float64",
          "y": "float64",
          "z": "float64"
        },
        "position": {
          "x": "float64",
          "y": "float64",
          "z": "float64"
        }
      },
      "pose_frame": "string",
      "uuid": "string"
    }
  ],
  "return_code": {
    "message": "string",
    "value": "int16"
  }
}

colliding_grasps: Liste von Griffen, die in Kollision mit einem oder mehreren Load Carriern sind.

collision_free_grasps: Liste von kollisionsfreien Griffen.

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

`save_parameters`¶

speichert die aktuellen Parametereinstellungen des CollisionCheck-Moduls auf dem rc_cube. 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`¶

stellt die Werkseinstellungen der Parameter dieses Moduls wieder her und wendet sie an („factory reset“). Dies betrifft nicht die konfigurierten Greifer.

Dieser Service hat keine Argumente.

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

CollisionCheck¶

Einleitung¶

Erstellen eines Greifers¶

Flanschradius¶

Erstellen eines Greifers über die REST-API¶

Erstellen eines Greifers in der Web GUI¶

Berechnete TCP-Position¶

Nicht-rotationssymmetrische Greifer erstellen¶

Kollisionsprüfung¶

Stand-Alone Kollisionsprüfung¶

Integrierte Kollisionsprüfung in anderen Modulen¶

Parameter¶

Übersicht der Parameter¶

Beschreibung der Laufzeitparameter¶

Statuswerte¶

Services¶

set_gripper¶

get_grippers¶

delete_grippers¶

check_collision¶

save_parameters¶

reset_defaults¶

`set_gripper`¶

`get_grippers`¶

`delete_grippers`¶

`check_collision`¶

`save_parameters`¶

`reset_defaults`¶