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, 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.
Lesezeichen