Hexapod - "IKU"

[oberallgeier]

... wir sollten das nächste Mal mal ein Erkennungszeichen ausmachen ...

... das wir sone Pins zum anstecken mit mindestens Community und dem Nickname ...

Ja, und ja. Ich hatte mir ein Schildchen, passend zu meiner Umhänge-Eintrittskarte ausgedruckt, große, dicke, deutliche Schrift - und recht früh das Halsband abgelegt; es war einfach ALLES zu heiß. Ich glaub ne Nadel mit aufgeklebtem RN-Logo (dazu Nick, evtl. "RN" - zur Erinnerung) im 20mmx20mm-Briefmarkenformat wäre praktisch. Evtl. für Sommertage auf Luftpostpapier *gg*.

... weil der Servo ein geregeltes System ist, kann man sich (unter einigen Randbedingungen natürlich) "sicher" sein...

Na ja, vielleicht bei teureren Servos. Aber auch dafür würde ich die Hand nicht ins Feuer legen. Über diese Pleite beim RS-2 hatte ich ja schon berichtet, der größengleiche HK-Typ von Pololu hat da sehr viel weniger Abweichung, erstmal kaum merkbar; wieviel konnte ich bisher aus Zeitmangel nicht er-messen. Aber das kommt - mit Bericht. Bei diesem Messaufbau will ich auch gleich mic´s Perioden-Pausen-Sensorik (mic - danke für die Erinnerung und den Link) aufbauen und testen.

[HeXPloreR]

Moin Moin,

ich wollte nur mal einen kurzen Zwischenstand abgeben:

Das Bascom Programm ist nun soweit umgeschrieben das jedes Bein seinen eigenen nächsten anzufahrenden Punkt bekommt.
Vorher hatte ich es ja sinngemäss eher so gelöst dass alle Beine das gleiche tun - sie standen also parallel und hatten dementsprechend auch die gleichen Winkel zurückzulegen um den Körper zu bewegen. Die Beine hatten auch noch keinen rechnerrischen Bezug zum Körper - auch das ist jetzt integriert, alle Berechnungen gehen vom "Centrum" (x=0; y=0, z=0) des Körpers aus. Und die IK berechnet, nachdem der Körper weggerechnet wurde, die einzelnen Werte für die Winkel.
Das herausrechnen des Körpers sollte insofern zum tragen kommen, wenn man den Körper kippen möchte, da sich hier die Winkel und Längen der Projektion des Körpers zum Boden ändern. Es wird hier also (hoffentlich) schon ein Grundstein mitgelegt, den man aber nicht nutzen muss.
Das Programm umfasst jetzt knapp 750 Zeilen Code - wobei man durch meinen vielen Kommis und Trennzeilen, bestimmt ca. 150 abzeiehn kann.
Das ergibt eine Datei die ca. 30 % der 32kB Flashspeicher benutzt.

Konkret bin ich jetzt dabei die Verschiebung des Körpers neu zu programmieren und auch meinen "ersten echten Schritt" zu erreichen.
Das soll auch einige Grundsteine für kurvengehen und dergleichen legen.

Leider sind doch einige Toleranzen in meinem Aufbau. Diese sorgen nun dafür das sich die Hüftservos nicht ganz sauber in einer Ebene drehen, und dadurch die Höhe etwas verreisst.
Das wird so bald wie möglich korrigiert.

[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

[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

[HannoHupmann]

Wozu brauchst du den OpenCM9.04 B? Erschließt sich mir nicht ganz, warum man einen weiteren Controller benötigt.