5 DOF Roboterarm: Arduino-Programme für Kinematik u. inverse Kinematik?

[HaWe]

es ist weniger eine Frage, ob man nicht auch mit int- oder long-basierten sin/cos/tan- und den entsprechenden arcus-Umkehrfunktionen arbeiten könnte, es ist eher eine Frage, wie man die Bewegung an einer Achse auf die nachfolgenden 3,4,5 Achsen weiterrechnet (das ist in dieser FK-Richtung eher vergleichsweise einfach), die Frage ist vor allem, wie man eine Soll-Position auf die mögliche(n) Stellung(en) der einzeln, nicht ganz frei beweglichen Achsen zurückrechnet (IK). Durch die Verkettung wird aus kleinen Fehlern am Anfang zum einen eine exponentielle Fehlervergrößerung bei den abhängigen Armgliedern, und zum anderen ist die IK-Rückrechnung bei 6 Armgliedern nicht mehr trivial und auch nicht eindeutig, und kann nur dann sinnvoll gelöst werden, wenn man den gesamten Arbeitsraum für alle erdenklichen Stellungen kennt.

Der Ansatz über Matrizen ist daher naheliegend und enleuchtend, auch wenn mir die Mathematik zu komplex für mein Verständnis ist:
Matrizen bieten sich deshalb sehr gut an, weil sie die Raumkoordinaten repräsentieren und die Bewegungsrichtungen, quasi tabellarisch zusammengefasst aus linearen Einzelpositionen und Einzel-Bewegungs-Vektoren. Das schöne bei Matrizen ist, soweit habe ich es verstanden, dass man sowohl eine geradlinige als auch eine Dreh-Bewegung als einfache Matrizenmultiplikation begreifen kann, es werden (sehr einfach ausgedrückt) nur andere Zeilen und Spalten miteinander multiliziert, einmal die linearen Positionswerte, und einmal die durch sin/cos- oder Winkelwerte (Bruchteile von Pi) eingetragenen Rotationswerte.

Man verkettet also alle Armglieder samt ihrer Rotations- und Stellungsmöglichkeiten über ein Matrizensystem, und über Matrizenmultiplikation erhält man bei gegebenen Winkeln eine Endstellung für die FK, ebenfalls als Matrize.

Hat man für die IK eine Anfangs- und eine eine Endstellung, die es zu erreichen gilt (beide als Matrizen), so wendet man nun exakt die gleichen Matrizenoperationen wie in der FK Hinwärtsrichtung an, allerdings invers, d.h. mit den inversen Bewegungsmatrizen, und zum Berechnen der Inversen Matrizen verwendet man u.a. deren Determinanten; Schritt für Schritt arbeitet man sich damit zu der Anfangsmatrix vor. Es ist wie eine Multiplikation in der FK Hinwärts-Richtung und eine Division in der IK-Rück-Richtung, und Division ist Multiplikation mit dem Inversen Element, also auch wieder Multiplikation:

theoretisch ist mir das klar, nur die Matrix-Mathematik dafür ist mir zu komplex. Es gibt dafür bewährte Konzepte (siehe Denavit–Hartenberg), doch für so etwas fehlt mir die mathematische Erfahrung und Kenntnis. Ich bezweifle auch ehrlich gesagt sehr, dass du, moppi, es ohne Matrizen schaffen könntest, was die IK Richtung angeht, aber lasse mich sehr gerne überraschen.

[Mxt]

Es ist nicht so, dass es da nur einen Ansatz gäbe.

Hier wird das für Anwendungen in der Computergrafik ein wenig beschrieben, gilt aber auch so für Roboter
https://wwwcg.in.tum.de/fileadmin/us...ikt_Hirmer.pdf

Was Moppi da andeutet ist im Prinzip der "analytische Ansatz" wie da in 3.4 beschrieben. Geht eventuell in CCD über, siehe Abschnitt 3.6.1.

Die oben verlinkten fertigen Lösungen verwenden die Methode, die da in 3.5.x beschrieben ist. Diese Jakobi-Matrizen funktionieren ein wenig anders. Sie geben im Prinzip an, wie sich der Tool-Center-Point ändert, wenn sich ein Gelenkwinkel ändert. Es ist quasi die Ableitung der Vorwärtskinematik. Die muss man dann invertieren, was ein Näherungsverfahren braucht, weil meist nicht invertierbar. Dann wird iterativ die IK-Lösung gesucht, wie im Link beschrieben.

Dann gibt es auch noch die Variante über halbwegs normale numerische Löser für Gleichungssysteme. Das ist auch wieder iterativ und braucht Rechenleistung.

[HaWe]

ja, klar gibt es nicht nur 1 Weg, aber eben bewährte und weniger bewährte. Meinetwegen auch noch 1 oder 2 neben Denavit–Hartenberg.
Aber die iterativen Lösungen scheiden faktisch bei >3DOF aus.

Zu moppis Ansatz mit integer-Arithmetik habe ich aber schon in einem anderen Topic etwas geschrieben:

Dabei muss man auch wissen, dass floats oder deren int16-Repräsentationen oft nicht genau genug sind, um bestimmte Berechnungen zu lösen (wie z.B. Matrix-Determinanten) und dadurch extremst falsche Ergebnisse liefern, daher muss man dann zwingend double verwenden.
Ich hatte schon oft bei meinen ersten Gehversuchen mit Matrizen mit dem Mega2560 (8bit-AVR, kann nur float, kein double) das "unerklärliche" Ergebnis, dass oft Determinanten einen Wert von deutlich größer null hatten (z.B. ein- oder zweistellig positiv), per float berechnet, obwohl die Matrizen antisymmetrisch waren oder ihre Zeilen nicht linear unabhängig, also die det(M) Null hätten sein müssen. Man kann eine Matrix mit Determinante Null aber nicht invertieren (genausowenig wie man durch Null dividieren darf), und die linearen Gleichungssysteme sind bei det(M)=0 nicht lösbar, und das falsche Ergebnis mit floats hätte dies fälschlich erwarten lassen.
Erst double-fp auf 32-bit ARMs erbrachte dann die korrekten Ergebnisse.

Dennoch, ish Suche ja eine Lib als Lösung, und wenn moppi meint er kann das mit seinem Weg machen, ist es mir ntl absolut recht, und ich warte dann gerne auf seine fertige Lib

[Mxt]

Ja, das hat dann weitreichende Bedeutung.

Der analytische Ansatz funktioniert ja nur für konkrete Roboter. Je nach Form des Arms, muss man die Dreiecke anders setzen. In der Regel braucht man auch Fallunterscheidungen, weil man je nach Gelenkstellung die Dreiecke anders setzen muss. Es ist aber das einzige bekannte Verfahren, die IK ohne Iteration zu lösen.

[HaWe]

Eben: es geht also bei float vs. double nicht (nur) um Genauigkeit des Endergebnisses, sondern u.U. sogar tatsächlich darum, ob das Problem überhaupt grundsätzlich lösbar ist.

Der analytische Ansatz funktioniert aber dennoch für viele verschiedene Roboterarm-Typen, wenn man anfangs die Geometrien (Winkel, Gliedlängen) definiert, die dann in die in der Lib mit ihren allgemein gehaltenen Matrizen mit den entsprechenden Platzhaltern per user-Interface-Funktionen eingesetzt werden.


PS, es hat auf meine Anfrage hin inzwischen jemand etwas "in Arbeit"...
https://github.com/henriksod/6DOFLib/tree/master/src
bin sehr gespannt...

[Moppi]

Da war noch was, durch Zufall gerade gefunden:

https://www.roboternetz.de/community...chs-Roboter%29

[Mxt]

es geht also bei float vs. double nicht (nur) um Genauigkeit des Endergebnisses

Ich glaube, das gehört in einen anderen Thread.

Ich glaube da hast du etwas noch nicht verstanden.

Analytischer Ansatz bedeutet eben den Verzicht auf die Platzhalter sondern die Aufstellung geschlossener Formeln speziell für einen Arm. Meines Wissens nach, wäre das die einzige Methode, um bei IK um Iterationen herumzukommen. Nicht Lösbarkeit zeigt sich dort dann in Division durch 0, unglültige Parameter bei Winkelfuntionen usw.

Deswegen schreibe ich ja, eine analytische Lösung, die sich über Eingabeparamter parametrieren lässt, wäre von allgemeiner Bedeutung. Meines Wissens nach gibt es das noch nicht.

Allerdings gibt es bei konkreten Roboterarmen noch eine zweite Ebene möglicher Unlösbarkeit. Ab 5-DOF ist ja, je nach Konstruktion, die Gelenkstellung des Arms aus dem TCP nicht mehr eindeutig herleitbar. (Analoges Beispiel: Man kann seine Hand auf der selben Position halten, aber den Ellenbogen dahinter bewegen.) Wenn jetzt ein Arm sein Werkzeug z.B. auf einer Linie bewegen soll, reichen für die einzelnen Punkte auf der Linie nicht mehr beliebige IK-Lösungen, man muss die ganze Linie mit konsistenten Ellenbogenpositionen fahren können.

[HaWe]

das verstehe ich anders:
analytische Geometrie verwendet ja gerade auch Matrizenoperationen, und um IK auszurechnen, dazu brauchst du u.a. die Inversen von den Ausgangsmatrizen.
Matrizen-Inverse existieren aber nur, wenn die Determinanten ungleich Null sind, und die det(M) gehen auch in die Berechnung der Inversen Matrizen mit ein.
Falsche det => falsche Inverse => Laufzeitfehler oder Rechenfehler per falscher Ergebnisse oder nans (Division durch Null, auch ohne Matrizen an dieser Stelle ntl., z.B bei Division durch sin(x) wenn x=pi).
@mxt: In den Matrizen stehen aber u.a. auch die Teilarm-Längen und die Orientierung der Drehachsen, und die kann man - trotz geschlossener Formeln - variabel halten pro Anwendungsfall.

@moppi: AVR Arduinos aber können kein double, das ist bei denen identisch mit float!!

Aber die Diskussion können wir uns eigentlich sparen, mein Ziel ist es ja nicht, so etwas selber zu programmieren, allein die Diskussion zeigt ja die Kompliziertheit überdeutlich: mein Ziel ist es, eine fertige Lib zu nutzen, egal ob von Henrik, von dir, mxt, oder von moppi

was das Ziel ist, habe ich indes ja bereits mehrmals geschrieben:

Beide Richtungen sind also wichtig:
a) Eingabe aller Einzelwinkel => Endposition des Greifers samt seiner Stellung (Eulerwinkel yaw, pitch, roll),
b) Eingabe einer Raumkoordinate samt Winkelstellung des Greifers => Berechnung aller Einzelwinkel

[Mxt]

Da kommt halt zweimal das Wort "analytisch" in etwas unterschiedlicher Bedeutung vor.

Im oben verlinkten PDF heißt es

Die Idee hinter diesem Ansatz ist es das Problem geometrisch mittels Kosinussatz zu lösen

Geht ganz ohne Matrizen. Aber eben nicht allgemein formulierbar.

Aber egal. Das Github-Projekt ist der eben schon zitierte Ansatz mit der Jacobi-Matrix. Und im Prinzip das, was alle von mir verlinkten fertigen Lösungen auch machen. Könnte sein, dass der Code auch irgendwie von der Matlab Vorlage abstammt. Kommt mir teilweise vor, als hätte ich Teile davon schon mal gesehen. Verwendet übrigens float, aber ich denke, das ist ok.

[Moppi]

Also Arduino kann cos, tan und sin. So weit ich gesehen habe mit Double. Ich denke mir, dass die Entwickler der Atmegas wissen, warum. Damit sollte man schon eine ganze Ecke weit kommen.

es ist eher eine Frage, wie man die Bewegung an einer Achse auf die nachfolgenden 3,4,5 Achsen weiterrechnet

Weiß ich bis jetzt auch nicht. Ich denke mir aber, dass sich vielleicht eine gemeinsame Basis finden lässt, eben was, was für jeden Motor Gültigkeit hat. Dann könnte man vielleicht alle nacheinander durchrechnen.

Ob sich Matrizen besser eignen würden, vermag ich nicht zu sagen. Man kann da sicherlich verschiedene Wege einschlagen. Allerdings hat man ja bereits sämtliche Winkel vorliegen, jederzeit. Winkel müssen nur neu berechnet werden, wenn sie verändert werden sollen. Addition und Subtraktion ist dort auch kein Geheimnis.

Am Ende kommt es drauf an, was Du machen willst. Es gibt einfache Lösungen, da wird der R-Arm angelernt. Dann führt er immer dasselbe aus. Dann kann man Teilbewegungen anlernen und kombinieren. Auch wieder eine Lösung. Dann hast Du ja jetzt diese Sache: ich kenne einen Punkt mit seinen Koordinaten und nun Blackbox sag mir bitte, in welchem Winkel jeder Motor zu steuern ist, damit ich den Zielpunkt erreiche.


MfG