Druckbare Version
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.
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... 8)
Da war noch was, durch Zufall gerade gefunden:
https://www.roboternetz.de/community...chs-Roboter%29
Ich glaube, das gehört in einen anderen Thread.Zitat:
es geht also bei float vs. double nicht (nur) um Genauigkeit des Endergebnisses
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.
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.
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.Zitat:
Zitat von HaWe
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
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 8)
was das Ziel ist, habe ich indes ja bereits mehrmals geschrieben:
Zitat:
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
Da kommt halt zweimal das Wort "analytisch" in etwas unterschiedlicher Bedeutung vor.
Im oben verlinkten PDF heißt es
Geht ganz ohne Matrizen. Aber eben nicht allgemein formulierbar.Zitat:
Die Idee hinter diesem Ansatz ist es das Problem geometrisch mittels Kosinussatz zu lösen
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.
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.
Vorgehensweise würde ich mal so versuchen:
Voraussetzung, das Ziel ist mit der Armlänge überhaupt zu erreichen.
Anhang 33667
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
ja, das klingt nach einem guten Ansatz, eben noch ein nur theoretisches Konzept, wobei noch rechts/links-Rotationen in manchen Teilarm-Achsen zu berechnen wären, nicht nur Abwickeln rauf/runter, samt Berechnung der Orientierung des Greifers (Schachfiguren senkrecht von oben mit den Fingerspitzen und Öffnung zur Seite, eine Flasche von beliebigen Seiten waagerecht mit der ganzen Hand, für schräg liegende Objekte mit einer diagonalen Position annähern und greifen...)
Aber wenn du so eine Lib mal in einem ersten Teststadium fertig hast, sag bitte gleich Bescheid, dann teste ich es hier gleich aus!