Du hattest ja letztens diesen Benchmark. Da sind Matrixmultiplikationen drin. Mehr braucht man für Richtung a) im Prinzip nicht.
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
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...
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:
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
Berechtigungen
Zitieren
Lesezeichen