Kinematik und Bewegung eines Knickarms

[Moppi]

Das Thema scheint irgendwie ein Problem zu sein: wie man Roboterarme steuert.

Deshalb habe ich etwas gesucht und habe mal eine kleine und kurze Erklärung gefunden.
Da ich die nicht vorenthalten will, hier mal der Link: https://micropede.de/shop/mp-robot-c
Den Inhalt der Seite dürfen wir sicher nicht hier her kopieren.




Es sind auch einige Erklärungen mathematischer Natur.
Das ist sicher nicht vollständig, aber als Ansatz für den Einstieg bestimmt brauchbar.

Es gibt dort auch einen Verweis auf eine Kinematikbibliothek bei github: https://github.com/glumb/mrc/blob/ma.../Kinematic.cpp


Etwas fortschrittlicher, aber auch komplizierter, als kleiner Einblick in die Thematik: Robotics Library (https://github.com/roboticslibrary)
Noch ein Projekt zu Kinematik: Orocos


MfG

[HaWe]

das Problem ist nicht die triviale Herleitung von FK und RK für 1 oder 2 Achsen, sondern für 6, und dabei auch noch Drehachsen neben den Knickachsen.
Und selbst bei 6-7 DOF ist die FK sogar noch grundsätzlich schrittweise lösbar, aber das eigentliche, viel größere Problem ist die RK!

[Moppi]

Es gibt eine Bibliothek dafür, die das kann? Ja, sie existiert irgendwo? dann muss sie gefunden werden.

Wenn es keine Bibliothek dafür gibt, muss man sich wohl selber eine Lösung erarbeiten.
In der Programmierung macht es Sinn, sehr komplexe Probleme auf jeden Fall zu zerlegen.
Wenn ich gar keine einfache Lösung finde, mache ich das auch so. Wohl wissend, dass das aufwendig ist (auch vom Code her). Wenn vermeintlich alle Teilprobleme erkannt sind, versuche ich zu verifizieren, ob anhand der Teilproblematiken die Ziele/ das Ziel erreicht werden kann. Fehlt was, kommt ein neues Teilproblem hinzu. Dann schaue ich, wie das vom Programm her unter ein Dach gebracht werden kann und löse ein Problem nach dem andern. Das dauert manchmal lange und es entsteht ein umfangreicherer Code, funktioniert aber in der Regel. Eventuell kommt man in den Teilproblemlösungen auch mit den einfachen math. Berechnungen aus. Du beschreibst das so: ist die FK sogar noch grundsätzlich schrittweise lösbar.

Die Erfahrung die ich in den Jahren gemacht habe, ist die, dass es in der Regel schwierig ist, den Weg hin zu finden. Wenn das alles einmal durchdacht ist und funktioniert, dann hat man alle Größen etc. im Überblick, die man benötigt. Und rückwärts geht es dann mit hoher Wahrscheinlichkeit einfacher.

Ein Lösungsansatz könnte sein, dass man schaut, welche Teilbewegungen man grundsätzlich benötigt, um alle Bewegungen, die infrage kommen, in diese Teilbewegungen zu zerlegen. Jede Teilbewegung benötigt dann wohl einen Trigger oder sogar mehrere. Wobei ich denke, dass nach sich jeder Teilbewegung die Trigger ändern können und meist werden. Nach diesen Triggern müsste man den Programmablauf und damit den Bewegungsablauf gestalten. Die Teilbewegungen lassen sich meinetwegen auch per Joystick-Methode einüben / speichern. Falls ich das nicht mathematisch auseinander nehmen will. Das würde aber vermutlich mehr Speicherplatz erfordern, wegen der vielen einzelnen Teilbewegungsmuster. Insgesamt würde ich daher auch nicht so kompliziert anfangen. Sondern mit erstmal nur einem Gelenk (die andern kann man ja zunächst starr halten). Wenn das gelöst ist, würde ich ein zweites Gelenk hinzunehmen. Auf diese schrittweise Erarbeitung komme ich irgendwann an mein Ziel, alle 6 Gelenke zu steuern. Vor allem lerne ich auf diesem Weg, wie einzelne Gelenke voneinander abhängen, wo die Trigger für dies oder jenes sind etc.

MfG

[HaWe]

ach moppi.... :-/
Es gibt Probleme, für die braucht man eben spezielle (mathematische) Fähigkeiten, um sie zu lösen, und die sind nicht einfach mit den Grundrechenarten und trivialer 2D-Geometrie für 1 oder 2 Winkel und allgemeinen ... äh... Statements lösbar.
Auch geht es nicht um Lookup-Tables aus Erfahrungswerten, sondern eine anylytisch-geometrische Lösung.

Dass das Problem grundsätzlich lösbar ist, zeigen die industriellen Roboter (z.B. von Kuka), und die einge standadrdisierte mathematische Beschreibungs-Ansätze wie nach Denavit-Hartenberg, die sich offenbar bewährt haben.
Sicherlich muss man also dazu nicht das Rad neu erfinden.
Robotiksteuerungen sind aber kein Metier, in das man sich "eben mal" so einliest, gerade RK ist derart komplex, dass dafür ganz sicher Fachleute gefordert sind, und hier im Forum sind ja nun bekanntermaßen viele Mitglieder vertreten, die sich mit Steuerungs- und Regelungstechnnik beruflich beschäftigen, denke ich zumindest, und wenn jemand dazu etwas sagen kann, dann vermutlich am ehesten diese Fachleute.

[Moppi]

Puhhh ...

Ich weiß, doch wo Dein Problem liegt: analytisch-geometrische Lösung. Um es mit Deinen Worten zu beschreiben. Da unterscheiden wir uns. Ich nenne das: rein mathematische Lösung. Ich versuche eben immer alles zu vereinfachen. Und damit erreiche ich auch meine Ziele - wie beschrieben.

Musst Du selber wissen, wie Du was machst.

Ich bin viel zu neugierig. Daher würde ich das Schritt für Schritt durchgehen. Wie oben beschrieben. Andere machen es auch nicht immer besser als ich (Bibliotheken verwenden). Und meist habe ich dann mit deren Lösungen auch so meine Probleme, die ich nicht hätte, wenn ich meine eigene Lösung habe.

Wenn man sich den Menschen anschaut, funktioniert das nicht durch kompl. mathematischen Berechnungen. Und der kann sich normal allemal besser bewegen, als jede Maschine. Aber nicht, dass Du jetzt denkst, ich wüsste nicht, dass eine Maschine einfacher aufgebaut ist und deshalb nur bestimmte Bewegungen zulässt. Ich meine hier die Ansteuerung der Aktoren und die Auslöser dafür.

Wenn man seine Lösung dafür erarbeitet hat, kann man das ja dann noch vereinfachen und auf einen mathemat. Punkt bringen (falls das bloße Funktionieren nicht zufriedenstellend ist), dann kommt bei dieser Historie ein weiterer Name hinzu (und eventuell ein bedeutender Preis auf der Weltbühne).

Für mich ist das Glas eben meist halb voll.

MfG

[HaWe]

per Lookup-Table habe ich es längst gelöst, für einen 4DOF Robot zum Schachspielen, für ca. 120 Felder (samt Parkpositionen) und verschieden große Figuren (s. Link unten).
Jetzt geht es aber um komplexe Bewegungsmuster wie z.B. Flüssigkeiten aus verschiedenen Gefäßen in Mixbecher oder Gläser einschenken, Schach-, Karten- oder Go-spielen oder Glühbirnen in verschieden orientierte Lampengewinde eindrehen. Da helfen keine 500 Milliarden Lookup-Tables, sondern nur allgemeingültige mathematische Lösungen.
Hinzu kommt, dass herkömmliche Servos gar keine Encoder besitzen, um eine willkürliche, manuell herbeigeführte Stellung auslesen zu können, damit sie irgendwie als Lookup-Pos. abgespeichert werden könnten.
FK und RK Algorithmen sind daher m.E. die sinnvollere, weil universelle und allgemeingültige Herangehensweise.