Hexapod - "IKU"

[HeXPloreR]

Hallo allerseits,

ist es wirklich schon wieder ein ganzes Jahr her seit ich hier zuletzt was geschrieben habe

Nun, was gibt es neues ... ich habe nun die Möglichkeit den Körper zur den Seiten und nach vorne/hinten kippen zu lassen.
Nur irgendwie hat sich hier ein (Denk-/Rechen-)Fehler eingeschlichen, anscheinend ist es mir bisher nicht möglich den Roboterkörper korrekt um einen virtuellen Punkt im Roboterkörper kreisen zu lassen.
Es funktioniert mit den äußeren Beinen - also beide Vorderen und beide Hinteren - wunderbar.
Aber mit den mittleren Beinen scheint es so zu sein als wenn die Beine nun schieben - also den Körper wegdrücken. Das soll so nicht passieren.

Ich habe nach meiner Skizze bei einer Verkippung nach vorne einen Winkelversatz berechnet. Nach der Skizze müsste sich dabei der Hüftwinkel der mittleren Beine ja geringfügig ändern da sich der Winkel der Beinhöhe auch entsprechend der Verkippung ändert. Die Nachführung dieses Servos bewirkt nun das schieben.
Ziel sollte es sein das beim Verkippen alle Fußpunkte am gleichen Ort bleiben und nur um ein virtuellen Drehpunkt im Roboterkörper gedreht wird. Dieser Punkt sollte auch fix sein. Das Ziel wird hier dementsprechend nicht erreicht bzw ich bin mit dem bisherigen nicht zufrieden.
Irgedwo hab ich noch einen Fehler in der Berechnung und komme nicht so recht drauf. Da die Verkippung mit den mittleren Beinen etwas anders berechnet ist, im Vergleich zu den vorder und hinteren Beinen, vermute ich hier natürlich mein Problem.

Ist meine Rechenansatz vielleicht grundlegend falsch und ich sollte von den Fußpunkten aus rechnen und den Virtuelle Punkt womöglich auch auf den Untergrund legen?
Momentan berechne ich aus der Mitte des Koordinatensystems (der fixe virtuelle Punkt im Roboter) wo die Fußpunkte wären wenn es gekippt wird.

Vermutlich liegt es an dem Schwerpunkt des Hexas, der ja nun mal irgendwo mittig liegt, deshalb fällt der Körper bei den vorder und hinter Beinen korrekt ab, aber drückt natürlich auf die Mitte und damit auch auf die Beine, die dann diese Verhalten produzieren.
Da es zwei Beine betrifft ist es für mich keine Alternative einen Schritt mit den betreffenden Beinen auszuführen.

Ich versuche demnächst mal die Berechnung umzuschreiben, so das der Abstand der Fusspunkte gleich bleiben muss und daraus dann die korrekten Beinwerte errechnet werden müssen. Ich denke da irgendwo wird der Fehler sein, denn ich ändere ja diesen Abstand - was wohl falsch ist. Logisch: Ändert sich dadurch ja der jeweilige Fußpunkt.

Wer hat eine Idee dazu?

Viele Grüße
Jörg

[HannoHupmann]

Bei meinem Vinculum habe ich verschiedene Ebenen der IK implementiert um über die komplexe Berechnung die Übersicht zu bewahren. Die beiden Kipp-Bewegungen um die x- und y-Achse (oder Längsachse, Querachse) sind im Prinzip durch die variable Höhe des Körpers zum Boden bzw. eben Abstand Schulter - Boden pro Bein definiert f(L, Q) = h(1..6). Ist die Höhe h für alle Beine gleich, dann steht der Roboter gerade auf dem Boden. Der Abstand der Fussspitze zum Schultergelenk wird automatisch berechnet, denn dieser ist eine Funktion der Höhe.

Der langen Rede kurzer Sinn: ich habe eine Ebene 0, bei der aus der Vorgabe: X,Y Koordinate der Fusspitze + Höhe, die Gelenkwinkel für die Servos hervor gehen.
In der Ebene 1 wird aus der Neigung L und Q das delta h für alle Beine berechnet. f(L,Q) = dh(1...6) + h(1...6). Später wird ein Neigungssensor erkennen wie "schräg" der Roboter steht und daraus eine Ausgleichsneigung bestimmen die er an die Ebene 1 übergibt.

Dabei ist es mir allerdings egal ob der Drehpunkt im Zentrum des Roboters liegt oder außerhalb, denn der Winkel für L und Q bleibt gleich.


Kleiner Nachtrag noch:
Die Koordinaten des Fusspunkts sind natürlich davon abhängig was maximal bei h + dh rauskommen kann. D.h. für Punkte sehr nahe am Körper ist viel h + dh möglich für Punkte sehr weit weg vom Körper nicht.

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

[HeXPloreR]

...
Bei deinem IKU ist das hintere Beinpaar noch Seitenverkehrt montiert, was die Berechnungen noch etwas komplizierter macht.
...

Naja, die IK-Berechnung ändert sich dadurch nicht. Ich berücksichtige die jeweilige Einbaurichtung erst einen Schritt vor der SD21-Werteübergabe indem ich von 1500 (neutral) abziehe oder dazurechne.

Ich habe das vorher gesagt nun zeichnerisch umgesetzt, dabei funktioniert der alternative Ansatz den HannoHupmann angesprochen hat nur wenn man zusätzlich die Längenänderung für diese Richtung beim kippen mitberücksichtigt damit alle Fußpunkte am selben Ort bleiben. Tut man das nicht landet man ungefähr bei dem Problem welches ich gerade schon habe.
Es entsteht also z.B. beim kippen nach vorne zusätzlich auch ein Differenz die von den vorderen Beinkoordinaten abgezogen und auf die hinteren Beinkoordinaten aufaddiert werden muss. Bei meinem Roboter ist das die Y-Länge. Diese Differenz ist umso gößer je höher der Roboter steht bei gleichem Kippwinkel. Dabei verschiebt sich der Roboternullpunkt nicht nur im Bezug zum Weltkoordinaten des Kippwinkels nach vorne, sondern es fällt die Höhe ab wenn man die Mittelbeine auf "dh2" = 0 belässt. Da dieser Höhenabfall sich gleichzeitig auf alle Fußpunkte bezieht kann er vermutlich vernachlässigt werden - könnte aber auch korrigiert werden.. Ob und wie sich das auf den Kippwinkel zur Seite auswirkt werde ich mir ansehen müssen.

Jetzt gilt es also das ganze programmiertechnisch am Roboter nachzuprüfen.

[HeXPloreR]

Hallo Leute,

ich habe nun endlich Mal einen guten Aufbau der Platinen für meinen Hexapod zusammen gesetzt.
Hier sieht man eine SSC-32 gepaart mit dem neuen Raspberry Pi 2 und dem Robotis OpenCM9.04 B Board.


Heute werde ich mich mit der ordentliche Verlegung der Leitungen beschäfftigen.
Sowie an der Software auf dem CM9 mit der inversen Kinematik weiter arbeiten.

Viele Grüße
Jörg