Hexapod - "IKU"

[HeXPloreR]

Vielen Dank HannoHupmann,

ich denke im Prinzip habe ich das auch schon so.... ich rechne auch die winkelabhängige Längenänderungen der X-Y-Achsen beim kippen in die IK mit ein und passe die Z-(Höhen-)Achse dementsprechen an. Wenn wenigstens meine Programmierung nicht falsch ist - von dem angesprochen Problem mal abgesehen - dann funktioniert es so. Allerdings stellt sich eben dieses Problem ein. Ich muss es wohl nochmal ganz langsam und genauestens prüfen und testen.

Eine Frage: Du berechnest also wirklich alle Beine gleich, oder weicht es auch mal irgendwo ab um etwa (mögliche auftretende) Sonderfälle abzufangen? ich frage das deshalb weil ich ja der Meinung bin ein Mittelbein wäre ein Sonderfall bzw anders zu rechnen als vorne und hinten.

Also nochmal das Problem in kurz: senke ich den Vorderkörper ab, steigt im gegensatz dazu der Hinterkörper auf - um den Nullpunkt drehend. Würde man jetzt die mittleren Bein in der Hüfte nicht nachführen würden sich die Fußspitze vom Boden entfernen und mit dem Verkippungswinkel nach hinten zeigen.
Es entsteht als ein kleines Dreieck, welches ich schon mit einrechne um die Änderung der beiden Fußpunkte abzufangen. Doch dabei entsteht das angesprochen Problem der nicht erwünschte leichte Bewegung des Roboters in die Gegenrichtung.

Hat jemand diese Problem auch schon gehabt und kann einen Tipp geben, woran es vemutlich liegt ...

Viele Grüße
Jörg

[rolber]

Hallo HexPloreR !!!

Ist denn wirklich schon wieder ein Jahr um?

Habe deine Ausführungen mit Interesse gelesen.
Kann mich noch schwach an die Anfänge beim Sensobot3 erinnern.
Der ist ja vom grundsätzlichen Aufbau deinem IKU sehr ähnlich.
Habe mir dann die erste Bewegungen mal angesehen:
http://youtu.be/43qlUMm7iYs
und die Programmierung angeschaut.
Wenn ich den Bot um die X Achse habe "kippen" lassen, wobei die x-Achse genau durch den Mitte der beide mittleren Beine geht, dann:
Bewegen sich die vorderen und hinteren Beine exakt umgekehrt mit den gleichen Werten.(Vorne Bot hoch , hinten Bot runter) und die mitteren Beine stehen auf der Stelle.
Wenn der Bot seitlich kippt, also Drehung um die Z-Achse, dann bewegen sich alle Beine auf der linken Seite nach Oben (Beispiel für eine Richtung) alle mit den gleichen Werten und auf der rechten Seite nach unten mit den umgekehrten Werten.

Also:
Je nachdem um welche Achse sich dein Bot dreht, ändert sich auch die Berechnung.
Bei deinem IKU ist das hintere Beinpaar noch Seitenverkehrt montiert, was die Berechnungen noch etwas komplizierter macht.
Wünsche Dir noch viel Erfolg und bin jetzt auch wieder etwas mehr dabei.
Leider bin ich Zeitlich so eingespannt, dass eine Antwort schon mal etwas länger dauert.

Hoffe ich konnte Dir helfen
MfG
Roland

[HeXPloreR]

Hallo Roland, schön was von Dir zu hören...

Ist denn wirklich schon wieder ein Jahr um?

jepp, ein Jahr ist wieder rum...man das ging echt schnell

Wenn ich den Bot um die X Achse habe "kippen" lassen, wobei die x-Achse genau durch den Mitte der beide mittleren Beine geht, dann:
Bewegen sich die vorderen und hinteren Beine exakt umgekehrt mit den gleichen Werten.(Vorne Bot hoch , hinten Bot runter) und die mitteren Beine stehen auf der Stelle.

Leider kann das nicht sein, dass er einfach da auf der Stelle steht. Weil sich beim senken und heben in einem Winkel der Fußpunkt ändern muss. *[EDIT] : Also ich denke Du machst es also auch schon richtig - nur wie war mir nicht ganz klar. [/EDIT]
Das einzige was ich mir mitlerweile vorstellen kann wie man es lösen kann, wäre die Verkippung nicht in die mittleren Beine einzurechnen sondern in die Vorder und hinteren je nach dem in welche Richtung gekippt wird, weil diese Beine es besser ausgleichen könnten. Das bedeutet ersteinmal ich rechne es schon mal falsch an dieser Stelle:/

Ich habe nur Probleme an dieser Stelle mit dem kippen nach vorne und hinten. Zur Seite passt alles.

Viele Grüße
Jörg

[HannoHupmann]

Ich brechne alle Beine gleich. Macht es einfacher. Beim Kippen um die x-Achse kommt als delta Höhe für die mittleren Beine eben 0 raus, damit bleiben sie auf der gleichen Position. Diese "Besonderheit" wird also von der hinterlegten Mathematik ganz von allein erschlagen. Um die Mathematik aufzustellen habe ich mir das immer auf einem Papier aufgemahlt und die Formeln aufgestellt. Danach die Formeln mit einem weiteren Beispiel überprüft. Da Kippen um x und y-Achse jeweils eine Höhenänderung bewirken hat also jedes Bein: dh = dh1 + dh2 (wobei dh1 z.b. kippen um x-Achse und dh2 kippen um die y-Achse bedeutet).

Im Prinzip könnte ich damit auch um die Y-Achse kippen, wenn diese nicht genau in der Mitte (im Schnittpunkt der mittleren Beine) liegt sondern nach vorn oder hinten verschoben ist.

Alternativ kann man für die y-Achse auch ein vereinfachtes Modell verwenden, wo man nur ein Bein berechnet und diesen Bein1, 2 = dh2 und Bein5,6 = -dh2 Wert verwendet und die beiden mittleren dh2 = 0 lässt.

[HeXPloreR]

Moin moin,

ja genauso mache ich es auch. Nur mit dem Unterschied das ich bisher eine extra Berechnung einschiebe um den Versatz zu berechnen und den dann ins Mittelbein einrechne.

Soweit ich jetzt verstanden habe kann ich es also nur so lösen, das ich den Versatz nicht ins Bein einrechnen sondern in den Körper. Der Körper kippt ja quasi nach vorne und zieht den "Roboternullpunkt" entsprechend des Winkels mit sich.

Konstruktiv bedingt ist es also nicht möglich den Nullpunkt zu fixieren ohne eine mechanisches schieben zu verursachen. Jedenfalls mit meiner Methode nicht.

Das bedeutet auch das ich mich bewusster vom Roboterkoordinatensystem aufs Weltkoordinatensystem begeben muss. Was ich bei den vorderen und hinteren Beine wohl tue, aber bei den mittleren Beinen fälschlicherweise ignoriert habe.
Einen gleichen Nullpunkt in beiden Systemen gibt es nicht, oder nur in einer Parallelstellung des Körpers zur (Welt)Ebene am Anfangspunkt. Zusätzlich wenn man davon ausgeht das der Roboter keine Schritte macht.

Ich bin mir nun sicher wo mein Fehler liegt und bedanke mich für den Gadankenaustausch.

Viele Grüße
Jörg

[HannoHupmann]

Ich bin mir zwar nicht sicher ob ich deinen Gedanken folgen kann, aber schön wenn wir helfen können. Meine Berechnung sind so aufgebaut, dass er die Kipp und Nick-Bewegungen auch wärend dem Laufen ausgleichen kann. Bisher habe ich das aber noch nicht praktisch getestet, denn ich müsste erst noch den Gyro implementieren. Allerdings brauch ich für diesen erst noch ein Matlab skript um die Werte kontinuierlich auszulesen, zu filtern und als grafik anzeigen zu lassen. Gerade an letztem scheitere ich aktuell. So ein schöner, durchlaufende Plott will mir nicht gelingen. Wobei ich es bisher noch nicht mit Simulink versucht habe, sondern nur über die GUI gearbeitet habe.