Das Koordinaten-Chaos
Ein häufiges Situation: Du hast eine Applikation, die auf Roboter A läuft. Aber Roboter A wird in ein neues Werk geschoben. Kann die Applikation mitgehen? Nicht ohne Änderungen an Dutzenden Positionen.
Oder: Ein Greifer wird gewechselt. Die neuen Greifer-Offsets sind anders. Jetzt muss man alle eingelernten Positionen neuanpassen.
Das ist teuer und fehleranfällig. Es braucht ein klares Frame-System.
Das Frame-Modell
Ein sauberes System hat vier zentrale Frames:
1. World-Frame
Das ist deine "Fabrik-Koordinaten". Absolut, unveränderbar. Der Ursprung könnte z.B. an der Werkstatt-Ecke sein. Alle anderen Frames sind relativ zu World.
2. Base-Frame
Wo steht der Roboter-Fuß in World-Koordinaten? Das wird einmal beim Setup definiert (z.B. per Kalibrierung) und dann nicht mehr angefasst. Wenn der Roboter später umgestellt wird, nur den Base-Frame neu kalibrieren.
3. TCP-Frame (Tool Center Point)
Das ist die Spitze deines Werkzeugs — relativ zum Robot-Wrist-Koordinatensystem. Mit einem anderen Greifer? Anderer TCP. Das ist eine einfache Konstanten-Änderung.
4. Objekt-Frames
Pallet, Tray, Teil-Position — all das hat seinen Koordinaten. Diese sind oft konfigurierbar, nicht hardcodiert.
Wie es in der Code-Praxis funktioniert
Du definierst:
- World-Ursprung = (0, 0, 0) im Fabrik-Koordinatensystem
- Base-Transformation = Wo der Roboter-Fuß in World ist
- TCP-Vektor = (100mm, 0, 50mm) vom Wrist-Koordinatensystem
- Pallet-Frame = wo die Pallet in World ist
Wenn du dann eine Position einlernst — z.B. "Greifen an Pallet-Position [0,1]" — speicherst du nicht den absoluten Joint-Winkel oder die World-Koordinaten. Du speicherst: "Position in Pallet-Koordinaten [0, 1]".
Zur Laufzeit rechnest du um:
Pallet-Position [0,1] + Pallet-Offset in World + Base-Transformation = World-Koordinaten = Roboter-Joint-Angles (via IK)
Der Vorteil: Wiederverwendbarkeit
Jetzt packst du denselben Code auf einen anderen Roboter-Typ. Sie haben unterschiedliche Kinematik? Kein Problem — die Transformation übernimmt die IK (Inverse Kinematics).
Die Pallet-Positionen? Dieselben. Die Sequenzen? Dieselben. Nur die Base-Kalibrierung und die TCP-Definition müssen neu gemacht werden — einmalig.
Das ist extrem wertvoll, wenn du eine Applikation auf mehrere Zellen ausrollst oder mit verschiedenen Hersteller-Robots arbeiten willst.
Im Framework integriert
Das C# Framework hat das Frame-System als Kern-Konzept. Frames sind erste-Klasse "Citizen" im Datenmodell, nicht Workarounds.
- Frame = (Position, Rotation) mit automatischer Transformations-Verkettung
- Jede Position speichert: "ich bin relativ zu Frame X"
- Transform-Chain automatisiert: "Pallet-Position in World-Koordinaten" wird mit einem Aufruf berechnet
- Kalibrierung via GUI oder API — nicht im Code hardcodiert
Dadurch entstehen Applikationen, die tatsächlich wiederverwendbar sind.
Best Practice: Dokumentation
Das Wichtigste: Dokumentiere dein Frame-System klar. Welche Frames gibt es? Was ist die Parent-Kind-Beziehung?
- World (root)
- → Base (Roboter-Position)
- → Wrist (End-Effektor des Roboters)
- → TCP (Tool Center Point)
- → Pallet-Frame
- → Tray-Frame (relativ zu Pallet)
Mit dieser Übersicht verstehen neue Entwickler sofort die Geometrie der Zelle.
Fehler vermeiden
Ohne Frame-System häufige Fehler:
- Eine Position wurde in Base-Koordinaten gelernt, eine andere in World → Zusammenstoß
- Greifer wurde getauscht, niemand updated TCP → Verfehlung
- Roboter wird umgestellt, keine Neu-Kalibrierung → Krabben-Bewegungen
Mit sauberen Frames sind das Nicht-Probleme.
Fazit
Das Frame-System ist nicht "optional" — es ist die Grund-Infrastruktur deiner Applikation.
Invest von Anfang an Zeit, ein klares Modell zu definieren. Die Payback kommt sofort bei der nächsten Wartung, Umstellung oder Wiederverwendung.