Archiv verlassen und diese Seite im Standarddesign anzeigen : [ERLEDIGT] Kinematik und Bewegung eines Knickarms
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.
33927
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/master/src/Kinematic.cpp
Etwas fortschrittlicher, aber auch komplizierter, als kleiner Einblick in die Thematik: Robotics Library (https://www.roboticslibrary.org/) (https://github.com/roboticslibrary)
Noch ein Projekt zu Kinematik: Orocos (http://www.orocos.org/kdl/release-102)
MfG
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!
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
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.
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
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.
Dann hast Du ein für Deine Soft- und Hardware ein spezifisches Problem. Und da Du Dich damit am besten selbst auskennst, sei es dann so, wie Du schreibst.
Dies Thema hier, geht generell mal um einen einfachen Ansatz und wie man zu Lösungen kommen könnte. Wir hatten hier ja schon Leute, die was derartiges bauen wollten und aber im Grunde mehr oder weniger Einsteiger sind oder nicht so viel Erfahrung mitbringen, weil sie eben noch keine 10 Jahre programmieren und softwaretechnisch Probleme lösen. Und da ich nun mal darauf gestoßen bin, was ich Eingangs verlinkt habe, habe ich die Information hier zur Verfügung gestellt. Einfach, damit man sich mal ein Bild machen kann, was auf einen zu kommt, damit man eine Vorstellung bekommt.
Ich bin natürlich darauf gestoßen, weil ich mal wieder gesucht habe, weil Du in Deinem andern Thema noch eine Lösung suchst. Aber dieses hier ist allenfalls eine Einsteigerinformation, deshalb habe ich das in ein extra Thema gepackt.
Aber:
Was man versuchen kann - habe ich auch selber schon gemacht - eine Universität suchen, wo man sich wahrscheinlich mit so etwas beschäftigt und dann dort mal ganz freundlich anfragen. Eventuell den Prof. für ein bestimmtes Fach (wo Du weißt, dass so etwas dort Thematik sein müsste) suchen und an den mal eine Anfrage stellen. Vielleicht bekommst Du dann nützliche Hinweise zur weiteren Vorgehensweise. Meist sind Lehrkräfte sehr, sehr hilfsbereit. Noch was dazu: ganz wichtig ist dann, dass Du das Problem genau auf den Punkt bringst und Dich sonst mit der Thematik weitgehend selbst beschäftigt hast - damit Du mit den Begriffen umgehen kannst, wenn Dir dann so jemand eine Antwort gibt. Man kann nicht mit komplexen Problemen hinkommen und erwarten, dass man sich dort an der Lösung stundenlang beteiligt. Es ist möglich, dass Du nicht mehr als einen Schubbser in die richtige Richtung bekommst.
MfG
nein, es ist ja gerade KEIN spezifisches Problem von mir persönlich, es geht ja gerade um eine allgemeine, universelle, auf alle möglichen Roboter-Arme und alle möglichen Anforderungen adjustierbare Lib für Roboter- FK- und RK- Steuerung.
Da gerade mit Arduinos weltweit extremst viele Probleme bereits mit universell verfügbaren und teils hochkomplexen Libs gelöst sind und sogar von Arduino selber ein Roboterarm vertrieben wird (Braccio mit 5 oder 6DOF), wären FK und RK eine wirklich sinnvolle Maßnahme.
nein, es ist ja gerade KEIN spezifisches Problem von mir persönlich, es geht ja gerade um eine allgemeine, universelle, auf alle möglichen Roboter-Arme und alle möglichen Anforderungen adjustierbare Lib für Roboter- FK- und RK- Steuerung.
Vielleicht kennt man dort an den Unis sogar was, was in die Richtung zielt und Dir weiter helfen könnte. Oder man kennt so eine Quelle sogar. Allerdings vermutlich nicht für Arduino etc. Das müsste man dann umschreiben.
MfG
dehalb frage ich hier im Forum, denn manche mögen ja noch aus ihrer Ausbildung und von ihren Kenntnissen über Fach- und Forschungsgruppen noch etwas mehr darüber wissen ;)
Wenn ich nicht aus Erfahrung sprechen würde...
Wenn wir so viel Fach- und Forschungsvertreter hier hätten, hättest Du sicher lange eine Antwort, denke ich.
Mach doch vielleicht einfach mal so eine Lib. Ich könnte sie später bestimmt gut gebrauchen. Wären dann vermutlich 5 Knickgelenke und 2 zum Drehen. Greifer rechne ich nicht ein.
MfG
Mach doch vielleicht einfach mal so eine Lib.
MfG
welchen Teil von "ich habe nicht die mathematischen Kenntnisse, um so eine analytisch-geometrische Lösung für RK zu schreiben" hast du nicht verstanden?
Ich habe auch nicht gefragt, wer so eine Lib NICHT KENNT, sondern wer eine KENNT (oder in der Lage ist, sie zu schreiben).
Wenn man seinen Arm in ROS mit URDF modelliert kriegt man mit TF2 beide Richtungen der Kinematik quasi geschenkt. Ansonsten verstehe ich auch nicht dein Problem mit mehr Gelenken nicht: Das ist einfach nur die Modellierung für 2 in Reihe gepackt. Auch mehr Freiheitsgrade sind nur: Mach deine Matrix größer
Wenn man seinen Arm in ROS mit URDF modelliert kriegt man mit TF2 beide Richtungen der Kinematik quasi geschenkt. Ansonsten verstehe ich auch nicht dein Problem mit 6 Achsen / Freiheitsgraden: Das ist einfach nur die Modellierung für 2 in Reihe gepackt. Auch mehr Freiheitsgrade sind nur: Mach deine Matrix größer
Zum Einen ist es ein Arduino-Problem, nicht ROS.
Aber zur FK: ja, ich schrieb ja, für FK ist das prinzipiell schrittweise lösbar, nicht aber für RK.
Mit Matrizenrechnung in desem Kontext kenne ich mich aber absolut nicht aus, ich kann sie weder passend definieren noch damit rechnen.
Stell dir vor, ich habe 3 Knick- und 3 Drehachsen (letztere für Basis + Unterarm2 + Handwurzel für Innen/Außenrotation), und ich will ein Objekt an Position (x=50cm,y=30cm,z=20cm) in einem Winkel von (yaw=25°,pitch=70°,roll=90°) greifen, und an den Gelenken sind max. +/- 90° Ausschlag zur Nullstellung möglich
- wie wären dann alle einzelnen Achs-Servos auszulenken?
\ /
\ / finger length 50 mm
|-| 6 claw spread
| metacarpal length 55 mm
|
o 5 metacarpal rotate
|
| wrist length 95 mm
|
v 4 wrist tilt
|
| forearm segment2 50 mm
|
o 3 forearm rotate
|
| forearm segment1 100 mm
|
v 2 elbow tilt
|
|
| upper arm length 180 mm
|
|
v 1 shoulder tilt
|
| shoulder height 15 mm
o 0 trunc rotate horiz
|
| trunc base 85 mm
|
___ floor
- - - Aktualisiert - - -
(berichtigt)
Da gibt es i.R. mehrere Lösungen. Kann man wenn man die FK kennt analytisch oder numerisch z.B. mit Mathematica bestimmen. Deshalb heißt das ja inverse Kinematik.
Das mit Arduino hatte ich nicht gelesen. Weil im ersten Post ja auch was von Orocos steht. Für einen Arduino bietet es sich an, im voraus eine analytische Lösung zu bestimmen und die mit bestimmten Zahlenwerten dann auszurechnen.
Wenn du Greifplanung mit reinbringst...viel Spaß ;) Würde ich mit Moveit am PC machen. Ansonsten ist man da ziemlich eingeschränkt weil das Planen eines Griffs ist wesentlich schwieriger als seinen Tool Center Point an eine bestimmte Position mittels IK zu bringen.
Da gibt es i.R. mehrere Lösungen. Kann man wenn man die FK kennt analytisch oder numerisch z.B. mit Mathematica bestimmen. Deshalb heißt das ja inverse Kinematik.
Das mit Arduino hatte ich nicht gelesen. Weil im ersten Post ja auch was von Orocos steht. Für einen Arduino bietet es sich an, im voraus eine analytische Lösung zu bestimmen und die mit bestimmten Zahlenwerten dann auszurechnen.
Wenn du Greifplanung mit reinbringst...viel Spaß ;) Würde ich mit Moveit am PC machen. Ansonsten ist man da ziemlich eingeschränkt weil das Planen eines Griffs ist wesentlich schwieriger als seinen Tool Center Point an eine bestimmte Position mittels IK zu bringen.
Genau deswegen wird ja eine fertige Arduino-Lib für 6D/7D FK+RK gesucht ;)
Im Vorraus lässt sich nichts bestimmen, alle Positionen und alle Greifwinkel sind nicht vorhersehbar (z.B. Greifarm auf Fahrroboter in wechselnder Umgebung und/oder für randomisiert auftretende Werkstücke) und müssen ad-hoc ausgerechnet werden können.
Bei mehreren möglichen Lösungen reicht 1 einzige, vorzugsweise die mit den minimalsten Einzelauslenkungen. 8)
Die RK muss quasi eine Funktion sein, die mit frei wählbaren (Ziel-) Parametern gefüttert wird (pass by value, so als wäre es eine mathematische Kalkulation mit frei wählbaren Summanden), und dann die zum Anfahren und Greifen notwendigen Einzel-Winkel zurückliefert.
Mach doch vielleicht einfach mal so eine Lib.
MfG
Wenn Du zitierst, dann bitte vollständig oder so, dass man erkennen kann, dass das Zitat ein Auszug aus dem ist, was geschrieben wurde.
MfG
- - - Aktualisiert - - -
... Weil im ersten Post ja auch was von Orocos steht. ...
Das ist nachträglich dazukommen, weil ich noch mehr Links fand und das nicht im Thema verstreut werden sollte. Das heißt, es sollte schon zusammenstehen, deshalb ist der erste Post geändert. Die Diskussion hintendran muss man ja nicht lesen.
Aber nichts desto trotz kann man mal schauen, was noch so existiert und daraus vielleicht auch Nützliches für die eigene Kreativität entnehmen.
MfG
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.