Hexapod - "IKU"

[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.