--- title: "Robotereinstellungen" description: "Robotereinstellungen in LumiScan VGR - JSON-Abschnitt robots mit Robotern, Greifern, Koordinatentransformationen, Wegpunkten und Pfadsegmenten." product: "LumiScan VGR" component: "lumiscan-vgr-de" version: "1.8.4" display_version: "1.8.4.8" latest_version: true language: "de" url: "https://docs.hdvisionsystems.com/de/lumiscan-vgr-de/json-settings/robots.html" --- # Robotereinstellungen – LumiScan VGR 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 - [RobotSettings](https://docs.hdvisionsystems.com/de/lumiscan-vgr-de/api/settings/robot-settings.html) ### Koordinatentransformationen - [Transform](https://docs.hdvisionsystems.com/de/lumiscan-vgr-de/api/settings/transform.html) ### Wegpunkte - [WaypointSettingsBase](https://docs.hdvisionsystems.com/de/lumiscan-vgr-de/api/settings/waypoint-settings-base.html) - [WaypointSettings](https://docs.hdvisionsystems.com/de/lumiscan-vgr-de/api/settings/waypoint-settings.html) - [Absoluter Wegpunkt](https://docs.hdvisionsystems.com/de/lumiscan-vgr-de/api/settings/waypoint-settings-waypoint-type-wp-absolute.html) - [Relativer Wegpunkt](https://docs.hdvisionsystems.com/de/lumiscan-vgr-de/api/settings/waypoint-settings-waypoint-type-wp-relative.html) - [Klon-Wegpunkt](https://docs.hdvisionsystems.com/de/lumiscan-vgr-de/api/settings/waypoint-settings-waypoint-type-wp-clone.html) - [Greifpunkt-Wegpunkt](https://docs.hdvisionsystems.com/de/lumiscan-vgr-de/api/settings/waypoint-settings-waypoint-type-wp-grip-point.html) ### Pfadsegmente - [PathSegmentSettings](https://docs.hdvisionsystems.com/de/lumiscan-vgr-de/api/settings/path-segment-settings.html) ## Hand-Auge-Kalibrierung: fest montierte und am Roboter montierte Kameras {#hand-eye-calibration} *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. | > [!IMPORTANT] > `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](https://docs.hdvisionsystems.com/de/lumiscan-vgr-de/plc-settings.html#moving-camera)). - **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](https://docs.hdvisionsystems.com/de/lumiscan-vgr-de/user-interface.html)). 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 {#recorded-capture-pose} 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//2026-09-22_14-03-51_123.png data//2026-09-22_14-03-51_123.ply data//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. > [!NOTE] > 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 {#move-frame} `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**. > [!NOTE] > 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.