Koordinatentransformationen im Raum

[Alsen]

Guten Tag,

undzwar habe ich folgendes Problem. In meiner Roboterzelle befindet sich ein Roboter und quaderförmige Objekte. Die Objekte sind als Punktewolken modelliert und auf ihren Oberflächen ist ein Koordinatensystem aufgespannt. Nun möchte ich das Koordinatensystem des Robotergreifers (Tool-KS)
so verschieben, dass es über dem Objekt-KS liegt. Das heisst der Greifer soll normal zur Fläche des Objektes auf dem das KS aufgespannt ist stehen.
Beide KS befinden sich in einem WELT-KS.
Ich weiß wie man über Transformationsmatrizen Punkte verschiebt und rotiert entlang von Koordinatenachsen, aber wie kann ich denn im WELT-KS mein TOOL-KS auf das Objekt-KS bewegen?
Würde das ganze in C++ programmieren.

Danke im voraus.
Beste Grüße Alsen

[shedepe]

Hallo prinzipiell (wenn ich dich richtig verstanden habe) fragst du ja nicht nach einer Koordinatentransformation sondern eher danach: Wie plane ich einen Weg so dass TOOL-KS über Objekt-KS liegt? Also ein Problem der Bahnplanung nicht des Rechnens.
Das jedoch wesentlich kompliziert (Je nachdem wie deine Robotergeometrie ist) weil du musst für deinen Roboterarm von seinem Startpunkt zu seinem Zielpunkt bewegen, dazu musst du in der Regel eine abfolge von erlaubten Gelenkwinkelkonfiguriationen generieren, die der Arm abfahren kann.

Um das ganze kurz zu umreißen: (Für eine fertige Lösung ist das Problem meiner Ansicht nach zu kompliziert)
1. Die gewünsche Zielpose des Arms im WELT-KS ausdrücken. Dazu kannst du die Normale zu der Flächeberechnen (Das zeigt dir Wikipedia: https://de.wikipedia.org/wiki/Normalenvektor). Dann wählst du z.B. den Mittelpunkt der Fläche aus und verschiebst ihn in Richtung des Normalenvektors soweit, wie du den Abstand zwischen Zentrum deines Tool-KS und deines Object-KS haben willst. Deine Orientierung ist die gleiche wie die des Objeckt-KS relativ zum Welt-KS.
2. Du musst irgendwie eine Bahn zwischen Start Pose deines Arms und ZIel Pose (die du in Schritt 1 erstellt hast) berechnen. Dazu gibt es z.B. in ROS fertige Bahnplaner. Aber einfach sind die nicht zu verwenden weil sie zwangsweise ein Kinematisches Modell des Arms brauchen.
3. Die berechnete Trajektorie musst du in erlaubte Gelenkwinkelkonfigurationen via Inverser Kinematik umrechnen (Bzw. viele Bahnplaner suchen auch nur im Gelenkwinkelraum nach Trajektorien)
4. Diese Trajektorie die als Abfolge von Gelenkwinkeln ausgedrückt ist, kannst du dann ausführen.

[Alsen]

Ich danke dir vielmals für deine schnelle Antwort!

Nach Absprache mit meinem Chef weiss ich nun, dass die Punktwolke mir für die einzelnen Punkte 6 Freiheitsgrade gibt, weswegen ich mit den rotatorischen Freiheitsgraden den Greifer automatisch ausrichten kann.
Demnach erspart mir das sehr viel Arbeit.

Danke dennoch für deine Mühen.

[i_make_it]

Das ganze erinnert mich an einen Teil des Leistungsumfangs von COSIMIR
https://de.wikipedia.org/wiki/COSIMIR

Ggf. hilft es sich mal da die Diplom und Doktorarbeiten anzusehen und deren Litteratur Verzeichnisse.
Bsp.:
https://eldorado.tu-dortmund.de/bitstream/2003/21662/3/Dissertation.pdf

Dort wurde die (Roboter)Zelle als Basis genommen, da sich ja der Roboter und jedes Objekt darin befinden.
Alle KS wurden also ins Welt-KS transformiert.
Wobei es damals (bei der Version mit der ich gearbeitet habe) noch keine Kollisionserkennung gab für Teile des Roboter die nicht zum Greifer gehörten.

Jedes Objekt wurde in COSIMIR als hiraschischer Baum aus 4x4 Matritzen beschrieben, so das man den Objektursprung in allen 6 Freiheitsgraden auf den Welt-KS Ursprung bezog und auf den Objektursprung dann Punkte und Flächen der Objekte.
Bei einem Roboter selbst wurde so dann auch die kinematische Kette von der Basis bis zum TCP aufgebaut.
Für inverse Kiniematik und Endstellungen waren dann Eigenschaften in den entsprechenden Objekten hinterlegt.

[Alsen]

Danke dir,

werde mir das ganze mal anschauen.
Letztendlich muss ich die inverse Kinematik in meinen C++ Code einbauen, da ich kaum was bisher programmiert habe könnte das schwer werden.

Kennt ihr denn vllt. fertigen Code für die inverse Kinematik, wo ich als Input nur die Objektkoordinaten brauche und dieser mir dann die Gelenkwinkel des Roboters wieder gibt ?
Anderweitig werde ich mich wohl mit Denavit Hartenberg auseinander setzen müssen und das ganze selber implementieren.
Koordinatentransformationen gehen in C++ denke ich mal über die Bibliothek eigen oder ?

Beste Grüße
Alsen

[shedepe]

Mein Tipp, schau dir ROS an. Da gibt es das alles als Nodes.

[Alsen]

ROS käme nach meinem Chef nicht in Frage weil es wohl nicht echtzeitfähig ist. Gäbe es denn keine Alternative oder zumindest eine mathematische Vorschrift nach der man nur den Input geben muss und dieser dann die Gelenkwinkel als Output wieder gibt.

[shedepe]

Wenn du keine Erfahrung mit Programmierung hast, ist Echtzeitfähigkeit etwas was du auch nicht mal eben nebenbei in einem Programm einbaust. Würde deinen Chef lieber von ROS überzeugen, es gibt mehr als genug Systeme die bewiesen haben, dass Echtzeitfähigkeit nicht zwangsläufig notwendig ist. Alternative wäre Orocos das kann Echtzeit, ist aber nicht soweit verbreitet.

Zur Mathematik. Prinzipiell erstellt man zu einer gegeben Kinematik eine Kette von Transformationsmatrizen die ausgehend von der Basis deine Koordinaten anhand des Gelenkwinkels vorwärts transformiert. Diese Kette kann man dann prinzipiell invertieren und damit von Koordinaten auf Gelenkwinkel schließen. (Im Zweifelsfall kann man das numerisch machen). Das Problem dabei ist, die Invertierung Singularitäten aufweisen kann und nicht eindeutig sein muss. Im Roboternetz wissen ist glaube ich auch ein Artikel dazu.

Um mal weiteren Fragen vorzubeugen -> Wir bewegen uns in Bereiche dabei in denen du dich selbst einarbeiten musst und nicht in einem Forum mal eben nebenbei eine Lösung dafür bekommst.

[HaWe]

Zu Kinematik und Inverser Kinematik s. z.B. hier:

https://homepages.thm.de/~hg6458/Robotik/Robotik.pdf (insb. S. 49ff, 62ff, 83ff.)
https://www.tu-chemnitz.de/informatik/KI/edu/robotik/ws2012/robotik_4.pdf (insb. S. 36ff, 53ff, 72ff.)

[schorsch_76]

Es muss nicht alles in Echtzeit sein. Servoregler müssen in Echtzeit regeln. Pfadplanung muss das nicht sein. Klassisch ist hier, bsp. Hardware Regelungen mit µC (Echtzeit System), Höhere Logik mit ROS oder anderem System. Damit baut man das System in Schichten/Layer auf. Wie so etwas gehen kann, zeigt das Video des Mars Rover Curiosity.

[1] https://youtu.be/3SdSKZFoUa8?t=9m49s

[Alsen]

Vielen Dank Leute, werde mir mal alles zu Gemüte führen.

Die einzige Frage, die sich mir stellt ist folgende:

Also über die Hand Auge Kalibrierung setze ich das Kamera-KS auf das Roboter-KS bzw. verschiebe es dahin.
Über die PointCloud erhalte ich 3 translatorische und 3 rotatorische Freiheitsgrade, welche über das Kamerasystem erkannt wird.
Somit ist dieser Punkt nach der Kalibrierung(was ja letztendlich auch nur eine Koordinatentransformation ist) ebenso im Roboter-KS.

Die inverse Kinematik also die Rückwärtstransformation findet doch also im Roboter-KS statt und dient nur dazu die 3trans und 3rot Freiheitsgrade in die 6 Gelenkwinkel des Roboters zu transformieren.
Stimmt das so ?