Du hattest ja letztens diesen Benchmark. Da sind Matrixmultiplikationen drin. Mehr braucht man für Richtung a) im Prinzip nicht.
Druckbare Version
Du hattest ja letztens diesen Benchmark. Da sind Matrixmultiplikationen drin. Mehr braucht man für Richtung a) im Prinzip nicht.
ja, diese einfachen Dinger habe ich mal irgendwo abgeschrieben, weil ich damals schon wusste, dass man ohne Matrizen für IK nicht auskommt (und um IK geht es ja ebenso), daher habe ich sie schon mal in den BrickBench mit reingenommen.
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
Aber wenn dir das bisschen schon reicht mit der Matrizenmultiplikation für so eine Lib, dann machs einfach damit 8)
Da geht ja was:
https://github.com/bolderflight/Eigen
Von einer der wichtigsten oben verlinkten Libs gibt es einen Port für den Teensy. Damit dürfte einiges aus dem Roboticbereich darauf laufen, ROS oder die Robotics Library der TU München verwenden alle Eigen.
das ist jetzt vielleicht ein kleiner Mosaikstein, aber nicht die Lösung der TOP Frage...
Zitat:
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
Na ja, es fertige Sachen. Zu einem ausgereiften Industriellen Roboterarm bekommt man sicher auch die passende Software, Dokumentation und Bibliotheken. Allerdings kann ich mir vorstellen, dass man dann dort wieder an eine andere Hochsprache gebunden ist.
Um einen Arm zu bewegen gibt es verschiedene Winkel, die entstehen, das wird nicht neu sein:
Anhang 33663
Hier noch mal Winkelberechnung, von ganz einfach bis kompliziert: https://www.frustfrei-lernen.de/math...l-rechnen.html
Wobei: kompliziert muss nicht sein. Meine Meinung. Daher würde ich persönlich zunächst einen andern Weg versuchen und die Winkel berechnen, die benötigt werden um den Punkt zu erreichen. Die Servos wollen doch wohl sowieso Winkel haben(!?). Berücksichtigen muss man, dass es auch negative Winkel gibt, also ob ich den Motor in die eine oder andere Richtung drehen lasse. Wenn ich das für eine Achse habe, würde ich das für die andere Achse auch noch machen. Hier wäre jetzt z.B. zuerst nur die X-Achse (Breite) und Y ist Höhe. Die Winkel entstehen hier zwischen diesen beiden Achsen. Dann bleibt noch die Z-Achse für die Tiefe. Z-Achse und X-Achse bilden einen rechten Winkel. Dazwischen befindet sich der Arm, bzw. die Armsegmente, wobei jedes wieder seine Winkel zur X-Achse und Z-Achse hat.
MfG
@moppi, bin gespannt wie weit du kommst, alle Autoren verwenden ja 32bit float und sogar 64bit double, um die nötige Exaktheit zu erreichen. Für 2 oder max. 3 Achsen/Gelenke ist das ja auch überschaubar, für 6 wird es aber schon deutlich anspruchsvoller, auch mit Drehungen in der Arm-Richtungsdimension, nicht nur für Knicken.
Aber nimm ruhig mal meinen 6DOF Robot mit den obigen Maßen und Achsgeometrien, die ich ja schon gepostet habe, sowie später dann auch anpassungsfähig für andere Arm-Geometrien vom 5- oder 6DOF-Typ, die davon abweichen:
bin sehr neugierig, was du hier für FK- und IK-Libs entwickeln kannst!
Ja tut mir leid, dass es Dir zu schwierig ist!
Das andere mit 256Bit Quaddouble rechnen müssen, heißt ja noch lange nicht, dass es nicht auch anders möglich wäre. Warum tun die anderen denn mit 32Bit Float und 64Bit Double - Typen rechnen? Was ist der Grund dafür? Willst Du es wissen? Ich sage es Dir: weil sie es nicht anders können oder weil sie es nicht anders können müssen.
Welche Genauigkeit hat denn so ein Motor? Wie genau solls denn sein? Auf ein Zehntel Millimeter? Ich bezweifle stark, dass das mit so einem Teil möglich ist!
Man stelle sich nur mal vor, dass man 1991 in 8Bit-Rechenoperationen Spiegelbilder in Kugeln in Echtzeit berechnet hat und dabei das Ganze noch auf den arschlangsamen Grafikkarten ausgegeben, wobei das dann das war, was die meiste Zeit verschlungen hat. Und dennoch war es flüssig möglich. - Klar auch mit dem ein oder anderen gerissenen Trick, ob mathematisch oder optisch. Obwohl, auch wie bei Doom - weil ich das schon mal anführte - auch mit einfachen 8 Bit vom Prinzip keine 3D-Welt berechnet werden konnte. Dafür musste man auch dort mit mindestens mit Nachkommastellen rechnen, was nur nicht wirklich ging, weil es keinen Co-Prozessor gab, mit dem man hätte in einem Rutsch einen Punkt im Raum berechnen können. Also was jetzt dann, gab es diese Spiele dann gar nicht, bilde ich mir das nur ein und viele andere haben einfach irgendeine Fata Morgana gesehen und sich was vorgemacht? - Natürlich nicht! Man kann auch mit 8-Bit Datentypen durchaus auf mehrere Nachkommastellen genau rechnen. Zum Glück ist das ja heute dann so nicht mehr nötig.
Es soll nur zeigen, dass man auch anders zum Ziel kommen kann, als nur auf irgendwelche Libs zu hoffen, die das richten werden.
Ich will Dir auch nichts aufschwatzen, wollte nur behilflich sein, mal eine andere Denkrichtung einzuschlagen. Wenn ich es bräuchte, würde ich mich damit auch auseinandersetzen. Tue ich aber eben jetzt nicht. Und in fünf Minuten ist das auch nicht erledigt, weil ich diese Problemstellung noch nie hatte. Da würde ich auch von vorne anfangen.
MfG
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.
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.
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:
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 8)Zitat:
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.