inverse kinematik für quatropoden

Hiho!

Bin gerade ganz neu auf diesem Gebiet und möchte in ferner Zukunft einmal einen Quatropoden oder Hexapoden bauen und jetzt zumindest die Mathematik der Programmierung verstehen:-) Dazu lese ich immer wieder von inverser Kinematik. Könntet ihr mir einen tollen Link geben, in dem das einmal nicht allgemein und wissenschaftlich aufgedröselt wird, sondern angepasst an einen Gehroboter?

Spezielle Frage dazu: So wie ich das verstanden habe, wird ja eine Soll-Position vorgegeben, an dem sich der Roboter (oder ein Stück davon) befinden soll. Dazu müssen sich dann die Servos geeignet bewegen. Aber wenn der Roboter jetzt geht, ändert sich seine Soll-Position ja ständig. Da weiss ich garnicht, wie die Servos (oder das Programm) dann darauf reagieren soll.

Rechnet man bei den Positionen im Raum mit Polarkordinaten oder mit kartesischen?

Ich hoffe, die "profis" schlagen jetzt nicht die Hände über dem Kopf zusammen... das sind die ersten Fragen, die sich für mich ergeben haben.
Mit der Suchfunktion kam ich da auch nicht weiter.

Danke schonmal im Voraus!

Hi und willkommen im Forum

hier ein kleiner Link wo es vielleicht nicht so ganz fachchinesisch beschrieben ist.
http://www.vreal.de/index.php?option...d=98&Itemid=83

Mich als nicht Mathematiker und ohne Abi, hat es etwas weiter gebracht

Hallo,

hab eben schon in einem anderen Thread darauf hingewiesen: Hier hab ich versucht, die inverse Kinematik für ein Hexapodenbein mal darzustellen. Vielleicht hilft es Dir. Ein wenig zu einer einfachen Laufkoordination findest Du hier.

Gruß
Malte

Ha, super!! danke, das hilft mir echt weiter. Damit beschäftige ich mich jetzt erstmal eine Weile:-)
Toll, dass es so schnell ging.

Hallo!

Nachdem ich nun ein bißchen gelesen und gerechnet habe, stehe ich immer wieder vor einem Problem. Zwar weiss ich, wo die Beine stehen sollen und wie die zugehörigen Gelenkwinkel usw. sind und auch welches Bein zu welchem Zeitpunkt bewegt werden soll.
Nur wie gebe ich die Signale für die Bewegungen. Ich möchte den Roboter gern mit einer Fernsteuerung bedienen, er soll also nicht autonom irgendwohin krabbeln. Wenn er jetzt das Signal "nach vorne gehen" bekommt, soll das Programm nicht "nur" die von mir berechneten Winkel der Servos einstellen. Die Formeln für die Berechnung sollen im Programm sein und dann abegarbeitet werden, sodass der Roboter sich selbst "überlegen" muss, welches Bein er wie bewegt. Die Inverse Kinematik soll der Robo also selbst berechnen.
Könnte jemand vielleicht mal schreiben, wie sein Signal zu "nach vorne gehen" ist und wie das Signal dann im Code verarbeitet wird? Also nicht mit Formeln, sondern nur, "was" das Signal bewirkt und was der Code darauf tut.

Viele Grüße!!

Du hast also schon herausgefunden, wie die IK berechnet wird? Gut.
Nun wäre der nächste Schritt, wie die Beinbewegung aussehen muss. Dazu brauchst du irgendeine Funktion im Raum, die die Bewegung der Fußspitze beschreibt. Im einfachsten Fall wäre das ein Rechteck, also Fuß hoch, Fuß nach vorne, Fuß runter, Fuß nach hinten. Diese vier Strecken müsstest du in gleich große Abschnitte einteilen (meinetwegen 5mm oder sowas). Der Ablauf wäre dann so, dass immer die folgende Koordinate verwendet werden würde.
Ein einfaches Beispiel:
Der Fuß soll 2cm angehoben, 3cm nach vorne bewegt, wieder 2cm nach unten und 3cm nach hinten bewegt werden, in 5mm Inkrementen. Die Folge der Positionen wäre also irgendwie sowas:
x y z
0 0 0
0 0 5
0 0 10
0 0 15
0 0 20
5 0 20
10 0 20
15 0 20
usw.
Dazu müsste noch ein Versatz gerechnet werden, da du ja vermutlich deinen Koordinatenursprung in der ersten Achse liegen haben wirst.
Nun müsste der Controller irgendwie diese Bewegung als Funktion implementiert haben. Nun wird immer nach einer konstanten Zeit die neue Koordinate berechnet und über deine IK die zugehörigen Winkel. Diese Winkel werden dann in das benötigte Servosignal umgerechnet und das Bein sollte dann die gewünschte Bewegung ausführen. Für die anderen Beine könnte man das ähnlich aufbauen.
Die Streckeninkremente in Kombination mit der Zeit, die dazwischen verstreichen soll, bestimmen die Geschwindigkeit. Am besten ist, wenn der Servo jeden PWM-Takt ein neues Signal bekommt, damit die Bewegung möglichst flüssig wird.

Dieser Algorithmus ist aber auch noch sehr einfach gehalten und ich bin mir sicher, dass es noch bessere Methoden gibt, damit die Bewegung nicht so hakelig wird.

Was mich aber noch interessieren würde: wie hast du vor, dass der Bot nicht immer hin und her kippt? Für eine Stabile Position braucht es immer mindestens 3 Punkte. Der Bot müsste also immer ein Bein nach dem anderen setzen.

Ah okay. Die Zahlen werden also vom Controller berechnet und nicht einfach dem Controller gegeben. Und der Versatz wird benutzt, damit man nicht für jedes Bein ein eigenes Koordinatensystem benutzen muss.
Erstmal baue ich mir ein Bein mit 3 Servos, um die Berechnungen auszuprobieren und zu üben.

Um auf deine Frage zu antworten: Genau, der Robo wird immer nur ein Bein nach dem anderen bewegen können. Vor dem ersten Schritt muss der Körper sich in eine Richtung bewegen, damit der Schwerpunkt zwischen drei Beinen liegt. Auch zwischen zwei Schritten muss der Körper wieder ausgerichtet werden. Und beim Ausrichten müssen auch noch fast alle Servos auf einmal bewegt werden. Oh man, beim Tippen merkt man so richtig, wie weit das noch weg ist:-)
Hier ist ein Link von einem supereleganten Gang!
http://www.youtube.com/watch?v=jWP3RnYa_tw

Ok, in dem Video mekrt man aber auch, dass der Programmierer versteht, was er da macht. Sieht wirklich sehr gekonnt aus.
Ansonsten hätte ich die Idee, dass man den Körper des Quadropods gleichmäßig über den Boden bewegen lässt, sodass sich die Füße auf geraden Bahnen bewegen müssen. Dabei wird dannimmer abwechselnd ein Bein nach dem anderen weiterversetzt. Ziel wäre es, dass beim normalen Laufen alle Beine in Bewegung sind, wobei immer drei Beine den Körper vorran bewegen, während das Vierte wieder nach vorne gehoben wird. Die Fußspitzen machen also alle dieselbe Bewegung, nur eben phasenversetzt. Das Nachvorneheben des Fußes müsste auch 1/3 der Zeit brauchen, die die anderen Beine den Körper vorranbewegen. Müsste man also die Geschwindigkeit anpassen. Wenn dabei immer das Bein bewegt wird, was schon am längsten aufgesetzt wurde, dürfte der Schwerpunkt auch gut liegen. Vielleicht wäre es ganz praktisch, das Ganze schonmal vorher irgendwie zu simulieren, also nur mit Fußpositionen, ohne IK. Interessant ist dann nämlich auch das Anlaufen bzw. Stehenbleiben, da die Beine dann ja nicht phasenversetzt sind. Beim Anlaufen müsste also das erste Bein einen Viertelschritt machen, das Zweite einen halben Schritt, das Dritte einen Dreiviertelschritt und die darauffolgenden Schritte sind dann immer vollständig. Mit der Methode könnte man es aber so machen, dass der Hexapod in alle Richtungen laufen kann, ohne sich zu drehen, also auch diagonal laufen, wobei sich der Körper im Idealfall gleichmäßig auf einer Bahn bewegt. Drehung müsste man dann gucken, wie man das realisieren kann. Wahrscheinlich mit Kreisbahnen, die einen gemeinsamen Mittelpunkt haben.
Du siehst schon, im Grunde geht es jetzt darum, die Bewegungen mathematisch beschreiben zu können, damit du mit den resultierenden Koordinatenverläufen und deiner IK die Servobewegungen errechnen kannst.

Ich hab mich zwar selbst noch nicht so sehr mit Multipods (ist das der Oberbegriff?) beschäftigt, allerdings beschäftige ich mich mit Roboterarmen und deren Bahnplanung. Daher dnek ich mal, dass man das Wissen hier anwenden kann, auch wenn ich noch keine konkreten Lösungen liefern kann, sondern nur Ideen. Und je mehr ich hier schreibe, desto mehr Lust bekomme ich, das mal irgendwann selbst zu probieren :D

Stimmt! Am besten wäre es wirklich, wenn der Körper sich gleichmäßig über den Boden bewegt. Dein Text liest sich, als wenn du wirklich viele Ideen dazu hast und es eigentlich auch mal ausprobieren möchtest haha. Für dich wäre das sicher nicht die riesige Herausforderung, wenn du dich schon mit Roboterarmen beschäftigst.

Wahrscheinlich werde ich mich in nächster Zeit auch mit einem Roboterarm (-bzw. dann dem Bein, aber man kann es ja nennen, wie man will:-D) beschäfitgen. Ich denke mal, dass es mit 3 Servos noch überschaubar bleibt, aber trotzdem gibt´s viel zu lernen!

Bin/War selbst am Planen von einem Quadropoden musste ihn aber aus Zeitgründen immer wieder nach hinten verschieben, leider. 3D Zeichnungen sind alle in sketchup erstellt und ein paar programme gibts auch schon, aber die Intelligenz und Sensoren fehlen noch. Wird aber angeganen, sobald ich meine CNC-Fräse feritg hab.

Wie hast du dir die Controller struktur von deinem Bot gedacht? Pro Bein 1 Controller oder für alle 12 Servos 1 Controller?
Bei mir hatte ich vor, 1 Servocontroller zu verwenden, der die IK berechnet und die Servos ansteuert. Als signal bekommt er X,Y,Z,alpha,beta,gamma vom Mittelpunkt des Roboters (also die Bewegung des Roboterzentrums), daraus berechnet er dann für jedes Bein die IK und steuert die Servos an. Vorteil von dem ganzen war, dass der Controller immer genau weiß, welches Bein in der Luft ist, und welches Bein geändert werden muss. Und das "Gehirn" (Hauptcontroller) sich um solche dinge keine Gedanken machen muss. Im Datenprotokoll waren aber auch vorgesehen Bein X an eine Bestimmte Position zu bewegen bzw. die Höhe von Punkten abzufragen um das ganze auch Geländegängig zu machen.

Geistesblitz hat auch das vorgehen von der Beinpositionierung beim Loslaufen gut erklärt. Beim stehen macht man es am besten genau so, sobald keine Bewegungsänderung mehr kommt, alle beine wieder auf die Ausgangsposition (is aber mehr für die optik :D ). Den einzigen Denkfehler, den er hat ist, das Bein, welches am längsten auf dem Boden ist zu ändern, denn das würde bei einem Richtungswechsel nicht mehr funktionieren. Besser ist es, zu schaun, ob deine Fußspitze aus einer Sicheren Zone (z.B. 5cm weg von der 0 Stellung) ist und es dann wieder auf 0 oder auf den gegenüberliegenden Rand der Zone zu setzen. Sind mehrere Beine gleichzeitig im "verbotenen Bereich" muss der Roboter stehen bleiben und sich erst wieder sammeln.

Ja, ich wusste es anders nicht besser zu beschreiben und das mit der Richtungsumkehr ist schon richtig, hab ich nicht dran gedacht. Eigentlich meinte ich schon das Bein, was am Weitesten von der Körpermitte weg ist.

Ein Roboterarm ist natürlich eine Ecke komplizierter als so ein dreiachsiges Bein, da es nicht nur um die Position, sondern auch die räumliche Orientierung geht. Da ist auch die IK nicht mehr so einfach zu erledigen.

Zum Controller: seit ich für meinen Roboterarm mit dem Servoboard von Pololu arbeite bin ich eigentlich recht begeistert davon. Es lässt sich relativ einfach über serielle Befehle (UART) steuern und kann je nach Board bis zu 24 Servos ansteuern. Soweit ich weiß kann man auch alle gleichzeitig ansteuern, müsste ich aber nochmal nachschlagen. Damit ließe sich der Hauptcontroller schon stark entlasten. Gibt sicherlich auch andere Servoboards, die sich verwenden ließen, aber von denen, die ich kenne, ist das von Pololu am anwenderfreundlichsten. Was nichts heißen muss, kenn ja auch noch nicht viele, guck dich am besten auch selbst mal um, was anderes würde ich jetzt auch nicht machen. Ich kann nur eine Empfehlung aussprechen ;)

Womit soll eigentlich die Bewegungsvorgabe geschehen? Programmgesteuert oder über einen Joystick/Joypad/Tasten/irgendwie sowas? Ich denk mal, letzteres wäre erstmal besser zu realisieren.

Man muss ja kein servocontroller kaufen, ein kleiner mega8 macht das auch (quasi software PWM) und kann dabei auch noch die komplette IK berechnen. -> entlastet den Hauptcontroller noch mehr.

Ja, aber den müsste man dann erst noch programmieren. Außerdem ist das Servoboard sehr kompakt, ich bezweifel, dass man das so viel besser selbst hinbekommt, erst recht als Einsteiger. Die IK wird dem Controller schon einiges abverlangen, das stimmt schon. Jedem Bein einen eigenen Controller spendieren und einen "Zentralrechner" einplanen ist allerdings auch eine gute Möglichkeit. Wär jedenfalls gut von der Modularität.

Hi!
Ich habe mir ehrlich gesagt noch gar keine Gedanken zur Controller Struktur gemacht. Wie gesagt, ich bin absoluter Neuling und muss mich erst einmal mit nur einem Bein beschäftigen. Ich weiss also auch nicht, wie gut ein Controller (ich benutze das Arduino UNO Board) mit dem Rechenaufwand klar kommt und wie gut ich ihn programmiert bekomme. Es wird also leider noch ein bißchen dauern, bis ich so konkrete Sachen planen kann:-D

Dann wird wohl das Sinnvollste sein, erstmal ein Bein mit Controller zu bauen und eventuell auch schon über den PC zu steuern. Dann wäre nämlich der nächste Schritt eigentlich nurnoch der Zentral-µC, die Kommunikation zwischen diesem und den Beinen und das Konzept der Beine lässt sich ja einfach kopieren. Erstmal mit einem Bein zu arbeiten sollte schon gehen, für einen Einsteiger zwar auch schon eine Herausforderung, aber schaffbar. Vielleicht auch vorher generell mit dem µC herumspielen, um sich mit diesem vertraut zu machen.

Jap, das denk ich auch. Am Herumspielen bin ich schon fleißig (jedenfalls, wenn ich mal wieder viel Zeit hab). Euch muss ich das ja nicht mehr empfehlen, aber trotzdem schreib ich´s nochmal kurz: Ich mache den Einstieg mit dem Buch "Die elektronische Welt mit Arduino entdecken". Mal sehen, wann ich wieder Neues berichten oder fragen kann:-D
Danke soweit schonmal für die vielen Tips!

Hi, ich wärme diesen thread mal wieder auf. Habe jetzt mit processing eine Simulation geschrieben, die über inverse Kinematik die Positionen eines Beins berechnet, wenn man x-, y-, und z-Koordinate vorgibt. Wie ich aus Geistesblitz´s Beitrag über die Bewegung eines Beines lesen konnte, kann man vorgeben: Bein 2cm heben, 3cm geradeaus, dann 2cm absetzen oder so.
Die Wegpunkte werden dann ja "ruckartig" von den Servos angefahren. Es gibt aber auch die Möglichkeit, etwas smoothere Bewegungen hinzubekommen, indem man sagt: alle Servos sollen sich so schnell bewegen, dass sie zur gleichen Zeit den Endzustand erreichen. Dazu benutzt man glaub ich die Jakobimatrizen. Sollte man sich das antun oder lieber mit Werten herumspielen, bis eine Bewegung einigermaßen flüssig aussieht?

Hallo,

du kannst doch einfach zwischen alter und neuer Zielposition des Fußes in mehr oder weniger kleinen Schritten linear interpolieren, diese Zwischenwerte in die inverse Kinematik stecken und die Positionen dann jeweils anfahren. Wenn man die Interpolationsschritte (räumlich und zeitlich) hinreichend klein macht, bekommt man damit durchaus eine einigermaßen flüssige Bewegung hin.

Gruß
Malte

Hallo!

Du brauchst keine Jacobi- oder sonstige Matritzen um eine schöne Bewegung hinzubekommen (wie auch malthy schon schrieb) - unter Umständen kann doch auch dein Vorschlag (alle Servos erreichen gleichzeitig den Endpunkt) zu Abweichungen führen?

Falls du Interesse hast: auf meiner Homepage gibt es Informationen, wie ich die Sache damals bei meinem Hexapod gelöst hatte.

Schönen Abend!

Ich denke bei einem Hexabot ist nicht die inverse Kinematik das eigentliche Problem. Die lässt sich ja bekanntlich recht leicht mit Sinus und Cosinus erschlagen und eine DH oder Jacobi Matrix wäre einfach zuviel des Guten. Das tatsächliche Problem kristallisiert sich in der Bahnplanung heraus. Sprich welche Trajektorie gibt man dem Roboter bzw. den einzelnen Füßen vor. Die einfache Aufgabe von A nach B zu laufen, wird dabei in eine Bahnkurve zerlegt die dann wiederum vom Roboter über die IK in die jeweiligen Servobewegungen umgesetzt wird. Ich kann mich erinnern, dass meine Bahnplanung beim Phoenix² nicht so gut war, ich konnte zwar die translatorische oder die rotatorische Bewegung vorgeben allerdings nicht kombiniert.

Für meinen neuen Hexa hätte ich gerne eine Kombination von beiden und zudem noch eine Lageregelung, so dass der Roboter seinen Körper unabhängig vom Untergrund waagrecht hält.
Jeder der sich ein bisschen auskennt wird nun erkennen, dass das eine mathematisch anspruchsvolle Funktion werden wird und ich weis auch noch nicht wie ich das realisieren kann. Vermutlich wird mir eh wieder die Mechanik des Roboters das Konzept verderben.

Abgesehen davon bin ich eher auf der elektro-mechanischen Seite beheimatet und kein Programmierfreak.