Kombination von Positionier- und Orientierungskinematiken
Mit dem Achsgruppenkonfigurator können Sie Positionierkinematiken und Orientierungskinematiken kombinieren. Dadurch kann mit einer kleinen Anzahl von Kinematiken eine große Vielfalt an Robotern konfiguriert werden.
Beispiele für Positionierkinematiken sind Portale (Kin_Gantry3) oder Tripoden (Kin_Tripod_Lin, Kin_Tripod_Rotary). Diese Kinematiken können eine beliebige Position anfahren, nicht aber beliebige Orientierungen herbeiführen. Das vorderste Koordinatensystem einer Positionierkinematik bezeichnen wir als Flanschkoordinatensystem. Es definiert die Stelle, an der eine Orientierungskinematik befestigt wird (linke Abbildung).
Beispiele für Orientierungskinematiken sind Kin_CAxis, Kin_Wrist2 und Kin_Wrist3. Diese Kinematiken können eine gewünschte Orientierung des TCP herbeiführen, aber nicht eine beliebige Position erreichen (rechte Abbildung).
Durch die Kombination einer Positionierkinematik mit einer Orientierungskinematik wird es möglich, beliebige Positionen innerhalb der gewünschten Orientierung anzufahren und umgekehrt.
Ungültige Kombinationen
Nicht jede Kombination einer Positionierkinematik mit einer Orientierungskinematik ist möglich, da manchmal die Rückwärtstransformation nicht eindeutig bestimmt werden kann. Ein Beispiel ist ein Scara mit zwei Gelenken als Positionierkinematik und Kin_CAxis_Tool als Orientierungskinematik mit einem Tool-Offset, der in der X- oder Y-Koordinate nicht 0 ist. Die Orientierung des Flansch-Koordinatensystems des Scaras ist nicht konstant. Sie ist gegenüber der 0-Stellung um die Z-Achse gedreht. Für die Berechnung der Rückwärtstransformation ist diese Drehung noch nicht bekannt, was die eindeutige Bestimmung der Achswinkel in diesem Fall unmöglich macht.
Ob eine Kombination möglich ist, kann erst zur Laufzeit geprüft werden, da es von der Parametrierung der Kinematiken abhängt. In diesem Fall wird der Fehler SMC_TRAFO_INVALID_COUPLING angezeigt.
Verhalten bei Programmierung von „unmöglichen“ Orientierungen
In der Praxis ist es oft nützlich, wenn man Orientierungen programmieren kann, die für die Kinematik eigentlich nicht erreichbar sind. Als einfaches Beispiel betrachten wir einen Scara-Roboter zusammen mit einem Werkzeug mit 1 Freiheitsgrad (Drehung um Z). Dieser Roboter kann prinzipiell nur Orientierungen annehmen, bei denen das Werkzeug senkrecht nach unten zeigt.
Wenn Positionen auf einem Werkstück angefahren werden sollen, wird dieses leicht aus der X/Y-Ebene heraus verkippt. Der Anwender teacht das Werkstück und programmiert dann die Positionen und Orientierungen relativ zum Werkstück. Durch die Verkippung des Werkstücks ergeben sich Orientierungen, bei denen die Werkzeugrichtung leicht aus der Senkrechten verkippt ist.
Wie gehen wir mit einer solchen „unmöglichen“, das heißt unerreichbaren Orientierung um? Eine drastische Maßnahme wäre die Meldung einer Arbeitsraumverletzung. Das würde aber, wie das Beispiel zeigt, die Programmierung mühsam machen. Daher sind die Orientierungskinematiken ( im Beispiel Kin_CAxis_Tool) so umgesetzt, dass sie die nächstgelegene erreichbare Orientierung annehmen. Im Beispiel bedeutet das: Die kommandierte Orientierung wird so gekippt, dass das Werkzeug senkrecht steht, und diese Orientierung wird dann angenommen.
Das Verhalten kann auf folgende Regeln reduziert werden (vorausgesetzt die Positionierkinematik kann in allen drei Raumrichtungen positionieren):
Die Position wird immer exakt angefahren (ansonsten wird ein Fehler gemeldet).
Die Orientierung wird, falls nicht erreichbar, auf die nächstgelegene erreichbare „projiziert“.
Bei der Projektion der Orientierung hat die Werkzeugrichtung Vorrang.
Die hier geschilderten Schwierigkeiten treten auf, weil die Orientierungskinematik nicht die drei Freiheitsgrade hat, um alle gewünschten Orientierungen zu erreichen. Dies ist bei Kin_Wrist2 und Kin_CAxis der Fall, aber nicht bei Kin_Wrist3.
Weitere Schwierigkeiten gibt es, wenn zusätzlich die Positionierkinematik nicht alle Freiheitsgrade im Raum hat. (Dies kommt in der Praxis nicht häufig vor.) Ein Beispiel ist die Kombination von Kin_Gantry2, einem Portal, das nur in X/Y positionieren kann, mit Kin_Wrist2, einem Werkzeug mit nur zwei Freiheitsgraden. In diesem Fall gibt es sowohl unmögliche Orientierungen als auch unmögliche Positionen, da die Z-Koordinate durch die Werkzeuglänge und die Stellung der Orientierungsachse bereits festgelegt ist. Daher empfehlen wir, solche Kombinationen nicht zu verwenden, oder in diesem Fall nur erreichbare Positionen zu programmieren.
Anmerkungen für selbst erstellte Kinematiken
Anwender, die selbst Positionier- oder Orientierungskinematiken erstellen wollen, müssen bei ihren Kinematik-Funktionsbausteinen folgende zusätzliche Schnittstellen umsetzen:
Für Positionierkinematiken: Die Schnittstelle
ISMPositionKinematics2mit den MethodenAxesToOrientationundGetOrientationImage.AxesToOrientationist eine „abgekürzte“ Vorwärtstransformation, die die Orientierung des Flanschkoordinatensystems aus den Achswerten berechnet. Sie ist nur aus Effizienzgründen nötig, da beispielsweise bei einem Portal hier nichts gerechnet werden muss, sondern eine konstante Orientierung zurückgegeben werden kann.GetOrientationImagegibt zurück, wie sich die Orientierung des Flanschkoordinatensystems verändern kann. Diese Methode ist nur für die Prüfung nötig, ob eine Orientierungskinematik mit der Positionierkinematik kompatibel ist.Für Orientierungskinematken: Die Schnittstelle
ISMToolKinematics2mit den MethodenGetPositionFromOrientation2undIsCompatibleWithPosKin.GetPositionFromOrientation2berechnet den Vektor zwischen dem Flanschkoordinatensystem und dem TCP aus der gewünschten Orientierung (im MCS). Diese Berechnung ist für die Rückwärtstransformation der kombinierten Kinematik nötig. Die MethodeIsCompatibleWithPosKinprüft, ob die Orientierungskinematik mit der Positionierkinematik kompatibel ist.