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

[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.

[HaWe]

Ja, sicher geht es auch ohne Matrizen, Matrizen "formalisieren und vereinen " ja nur einzelne "normale" trigonometrische Berechnungen, die man auch für sich genommen einzeln durchführen kann, nur dadurch eben "handhabbarer" auch für Rückrechnungen, und daher sind Matrizen für die, die was davon verstehen, universeller und einfacher zu verwenden, samt aller ebenfalls per Matrizen formulierter Hilfs-Libs (wie Eigen und Denavit–Hartenberg etc.).

Und ja, der Autor hatte bereits auf eine ihm bekannte und von ihm genutzte MATLAB Lösung hingewiesen. Der Link zur Denavit–Hartenberg Konvention stammt in diesem ZUsammenhang auch von diesem Autor, diese beschreibt ja v.a. die Achs- und Arm-Winkel-Stellungen in Matrizenschreibweise.

Float reicht übrigens auch für die FK, nur für die det und die Inversen für die IK wird man eher double brauchen. Darüber hatte ich schon mit dem Autor gesprochen. Die IK aber ist ja noch überhaupt nicht fertig.

[Moppi]

Vorgehensweise würde ich mal so versuchen:

Voraussetzung, das Ziel ist mit der Armlänge überhaupt zu erreichen.



Wie könnten die einzelnen Armsegmente nun ausgerichtet werden?

Das kann man so machen, dass der Anfang meiner geraden Linie, der Basispunkt (Bezugspunkt/Standpunkt)
meines Arms ist. - Das kann nur der erste Drehpunkt sein. Das Ende meiner geraden gedachten Linie ist
das Gelenk am Greifer (hinzu kommt die Greiferlänge, muss berücksichtigt werden bei der Gesamtlänge).
Nun dreh ich alle Gelenke so, dass der Anfangs und Endpunkt auf meiner gedachten geraden Linie zu liegen kommen.
Aber nicht irgendwie, sondern so, dass genau die Entfernung überbrückt wird, die ich bis zum Zielpunkt habe.


1. Möglichkeit jetzt: Die Summe aller einzustellenden Winkel hat eine bestimmte Größe.
Die gedachte Linie (gerade Entfernungslinie) kann man als Durchmesser eines Kreises sehen.
Die Summe aller Winkel an den Drehpunkten müsste im Zusammenhang mit dem Durchmesser eines Kreises stehen.
Die Winkel sind aber auch abhängig von den Segmentlängen des Arms. So dass man das insgesamt vielleicht
über Dreiecke ausrechnen kann.

2, Möglichkeit: Wenn man die Segmente einstellt, so dass sie eine bestimmte Strecke überbrücken, kann man die Winkel messen.
Die Winkel müssen im Zusammenhang mit der überbrückten Strecke und den Segmentlängen stehen. Wenn das ein
paar mal wiederholt wird, sollte sich etwas zu erkennen geben, womit ich was anfangen kann und also dann
die Winkel für die Überbrückung jeder beliebigen Strecke berechnen kann. Vielleicht nimmt man dazu Pappstreifen, bindet
die an den vorgesehenen Drehpunkten zusammen und probiert das auf einem Tisch mal aus.

Die Lösung dafür parat habe ich jetzt auch nicht, bin viel zu lang aus der Materie raus. Mein ehemaliger Mathelehrer
wüsste sicher weiter.

Wenn ich das aber weiter spekuliere, denke ich, dass die Winkel an den Drehpunkten zwar immer abhängig von den
vorhergehenden Segmentlängen sind, dass sie aber in einem festen Verhältnis zur überbrückenden Strecke stehen.
Diese Verhältnis würde man aber nur einmal ausrechnen, weil sich die Segmentlängen ja nicht dauernd ändern. Man könnte
theor. also von der Länge direkt auf die einzelnen Winkel schließen.




MfG