Robotereinstellungen

Der Abschnitt robots definiert die Roboter, Greifer, Koordinatentransformationen und Bewegungsinformationen, die für die Roboterinteraktion erforderlich sind.

Ein physischer Roboter kann durch mehrere Konfigurationen dargestellt werden, beispielsweise wenn verschiedene Greifer verwendet werden. Die Robotereinstellungen beschreiben außerdem die Positionen und Bewegungssegmente, die zum Anfahren und Ausführen eines Griffs erforderlich sind.

Roboterparameter

Koordinatentransformationen

Wegpunkte

Pfadsegmente

Hand-Auge-Kalibrierung: fest montierte und am Roboter montierte Kameras

Ab v2.0.0.

Jeder Robotereintrag gibt mit cameraMountType an, wo seine Kameras sitzen:

cameraMountType Bedeutung

STATIC (Standard)

Keine Kamera dieses Roboters wird getragen. cameraToRobot enthält eine Hand-Auge-Transformation pro Kamera, von der Kamera zum Basiskoordinatensystem des Roboters, und cameraToMove wird nicht gelesen. Das ist das Verhalten aller Projekte, die vor der Eye-in-Hand-Unterstützung erstellt wurden, und ein Projekt, das cameraMountType nicht setzt, behält es.

MOVING

Der Roboter trägt die in cameraToMove aufgeführten Kameras. Diese Zuordnung enthält eine Hand-Auge-Transformation pro Kamera, von der Kamera zum Move-Frame des Roboters (dem Link, den moveFrame nennt, normalerweise der Flansch), nicht zum TCP. Diese Kameras benötigen für jede Aufnahme die aktuelle Move-Frame-Pose des Roboters. cameraToMove darf nicht leer sein.
cameraMountType ist die Voraussetzung, nicht die ganze Antwort. Welche Kameras ein MOVING-Roboter tatsächlich trägt, wird pro Kamera entschieden, danach, ob die Kamera in cameraToMove aufgeführt ist. Eine Kamera desselben Roboters, die dort nicht aufgeführt ist, gilt als fest in der Zelle montiert: Sie wird weiterhin über cameraToRobot aufgelöst und benötigt keine Pose. Ein Robotereintrag kann daher gleichzeitig eine Handgelenkkamera und eine Überkopfkamera bedienen, und nur der Handgelenkkamera muss eine Pose übergeben werden.

Der Move-Frame wird aus zwei Gründen statt des TCP verwendet: Es ist das Koordinatensystem, das der Roboter ohnehin meldet (IN_PoseMoveInRobot an der SPS-Schnittstelle und die Pose, die GetBestResult über OPC UA zurückgibt), sodass beide ohne weitere Umrechnung kombiniert werden; und er ändert sich nicht, wenn der TCP neu eingelernt wird, sodass das Neueinlernen eines Greifers keine Kamerakalibrierung ungültig macht.

Die Pose wird übergeben mit:

  • SPS (PROFINET): IN_PoseMoveInRobot schreiben. LumiScan VGR übernimmt eine Momentaufnahme davon, wenn es IN_TriggerCameraRequest bearbeitet (siehe Am Roboter montierte Kamera).

  • OPC UA: CaptureImageWithPose aufrufen, oder SetCapturePose gefolgt von CaptureImage. SetCapturePose kann auch nach einer Aufnahme und vor ComputeObjects aufgerufen werden; bereits mit der vorherigen Pose berechnete Ergebnisse werden verworfen und mit der neuen neu berechnet. GetCapturePose liest die aktuell gültige Pose zurück.

  • Benutzeroberfläche: der Dialog Set Capture Pose…​ (A15).

In jedem Fall wird die Pose im eigenen Posenformat des Roboters angegeben, mit den in poseFormat konfigurierten Einheiten und der dortigen Rotationskonvention. Sie ist damit genau das, was der Roboter meldet und was LumiScan VGR als Greifpose zurückgibt.

Wird mit einer getragenen Kamera eine Aufnahme versucht, ohne dass eine Pose übergeben wurde, schlägt sie mit MISSING_ROBOT_POSE fehl, statt eine Pose zu raten. Eine nicht getragene Kamera desselben Roboters ist davon nicht betroffen und nimmt normal auf.

Die gespeicherte Aufnahmepose

Eine Aufnahme mit einer getragenen Kamera lässt sich nur zusammen mit der Pose auswerten, in der der Roboter stand. LumiScan VGR speichert diese Pose daher mit der Aufnahme und liest sie beim Abspielen der Aufnahme wieder ein.

Wird eine Aufnahme exportiert (exportPcl oder exportCenterView) und trägt der Roboter die aktive Kamera, wird neben der Aufnahme eine nach ihr benannte Datei geschrieben:

data/<cameraId>/2026-09-22_14-03-51_123.png
data/<cameraId>/2026-09-22_14-03-51_123.ply
data/<cameraId>/2026-09-22_14-03-51_123.pose.json

Sie enthält die Move-Frame-Pose in Roboterbasiskoordinaten zweimal:

  • moveToBase: die 4x4-Transformation in Metern. Eine Wiedergabe verwendet diese, sodass eine Aufnahme lesbar bleibt, auch wenn das poseFormat des Projekts später geändert wird.

  • robotFormat: dieselbe Pose im eigenen Format des Roboters, also die Zahlen, die das Roboter-Bediengerät anzeigt. Sie wird nicht als Pose eingelesen, sondern beim Laden mit moveToBase verglichen, sodass ein geändertes poseFormat als Warnung sichtbar wird, statt stillschweigend die Bedeutung jeder gespeicherten Zahl zu ändern.

Wird der Ordner mit --simulate-camera abgespielt, wird die Pose automatisch übernommen, sodass eine Eye-in-Hand-Aufnahme reproduziert wird, ohne die Pose erneut von Hand einzugeben. Das gilt nur für eine simulierte Kamera; eine reale Kamera erhält ihre Pose immer wie oben beschrieben von der SPS, über OPC UA oder über die Benutzeroberfläche.

LumiScan VGR kann eine simulierte Kamera derzeit nicht fragen, welches Bild sie gerade abgespielt hat. Ein Datensatz, der aus einer Roboterposition aufgenommen wurde, wird daher exakt wiedergegeben; ein Datensatz aus mehreren Positionen protokolliert eine Warnung mit der verwendeten Pose, und nur die bei dieser Pose aufgenommenen Bilder sind korrekt. Teilen Sie eine solche Aufnahme in einen Datensatz pro Roboterposition auf.

Eine Posendatei, die fehlt, nicht lesbar ist oder keine gültige starre Transformation enthält, wird gemeldet und ignoriert; die Aufnahme schlägt dann mit MISSING_ROBOT_POSE fehl, genauso als wäre keine Pose übergeben worden.

Was moveFrame benennen muss

moveFrame ist der Name eines Links in der URDF-Datei. Die Wahl ist nicht nur kosmetisch: Es ist die eine Einstellung, von der drei Dinge abhängen, und nichts anderes in LumiScan VGR verwendet sie (inverse Kinematik, Bahnplanung, Kollisionsprüfung, Wegpunkte und die 3D-Ansicht sind davon unabhängig):

  1. Was LumiScan VGR meldet. OUT_PoseMoveInRobot (PROFINET), GripPointPose (OPC UA) und die Trajektorie sind die Pose dieses Links in baseFrame, also die Pose, die der Roboter anfahren soll. Zeigt moveFrame auf einen anderen Link, verschiebt sich jede angefahrene Pose um die Transformation zwischen beiden Links, ohne jede Fehlermeldung.

  2. Was der Roboter meldet. Bei cameraMountType MOVING muss die in IN_PoseMoveInRobot geschriebene (oder an SetCapturePose übergebene) Pose die Pose genau dieses Links sein.

  3. Wogegen die Kamera kalibriert wurde. cameraToMove wird von der Kamera zu genau diesem Link gemessen.

moveFrame ist optional. Ab v2.0.0 bedeutet ein fehlendes moveFrame den TCP: den Endeffektor der URDF (ihren einzigen Blatt-Link), den die inverse Kinematik auf jede Greifpose setzt. Nennen Sie stattdessen den Flansch, wenn die Robotersteuerung in Flanschkoordinaten angesteuert wird (kein Werkzeug in der Steuerung konfiguriert). Vor v2.0.0 fiel ein fehlendes moveFrame auf baseFrame zurück, und ein separates tcpFrame benannte den TCP.

Bei cameraMountType MOVING muss sich moveFrame von baseFrame unterscheiden; andernfalls wird die Einstellungsdatei beim Laden zurückgewiesen, denn eine Kamera kann nicht an einem Flansch montiert sein, der die Roboterbasis ist.

Eine URDF kann den Move-Frame über ein floating-Gelenk anbinden, und das Standard-Robotermodell von LumiScan VGR tut genau das: robot_base --(floating)-→ flansch --(fixed)-→ tcp. Die inverse Kinematik platziert dann einen frei schwebenden Flansch, statt einen realen Arm zu modellieren. Eine Eye-in-Hand-Kamera ist davon nicht betroffen: Das schwebende Gelenk liegt oberhalb des Move-Frames, die Kamera starr darunter, und die Transformation von der Kamera zur Basis wird allein aus der übergebenen Pose und cameraToMove berechnet, ohne die URDF.