.: Vinculum :. - Hexabot

[HannoHupmann]

Eigentlich ist es sogar egal ob der Bot eine Gerade läuft oder eine Kurve, wenn man die Kurve in kleine Strecken unterteilt "merkt" der das nicht mal wirklich.

Schon richtig, aber irgendjemand muss ihm ja sagen, wohin der nächste kleine Schritt gehen muss. Also kommt wieder die Bahnkurve ins Spiel.

Worauf ich im Prinzip hinaus will lässt sich ohne Probleme als Mensch machen. Geh einfach zur Türe des Zimmers und dreh dich dabei einmal um 360°, danach läufst du mit Blick zur Wand zurück zum PC. Jeder bekommt das hin, sich durch den Raum zu bewegen und dabei um seine Achse zu drehen oder quer zu laufen mit dem Gesicht in eine bestimmte Richtung. Genau das Gleiche geht mit einem Hexa auch, wenn die Mathematik dahinter gut genug ist.

Jetzt stellt man entweder jedem Bein eine eigene Kurve für die Fußpunkte bereit...

Darauf läuft es hinaus und die Mathematik dafür gilt es zu entwickeln.

...oder lässt je eine Beinseite auf nur einer Kurve laufen

Wenn ich dich richtig verstehe, willst du in etwa das implementieren was auch ein Panzer macht. Er bewegt eine Seite schneller als die Andere (nur eben Ketten statt geraden Stückchen) bzw. bei dir länger und kürzer. Finde ich persönlich nicht besondern effizent, wenn man Beine hat. Bei meinem Phoenix² hatte ich bereit für jeden Fuss eine eigene Kurve, alles andere reduziert die Möglichkeiten doch schon sehr.

Im Prinzip ist meine Steuerungen für den Hexa in mehreren Ebenen angelegt:
1a Ebene: Inverse Kinematik: Es werden aus der Vorgabe die Winkel der Servos alpha beta gamma berechnet
2 Ebene: Inverse Kinematik: Position der Fussspitze im Raum bestimmt durch f(x,y,h)= alpha, beta gamma übergeben an die Ebene 1.
2 Ebene: Inverse Kinematik: Lage des Körpers, kippen um die Längs und die Querachse f(Q, L)=dh und Übergabe der daraus resultierenden Höhenänderung
3a Ebene: Bahnplanung Fusspitze: Schritt: Vorgabe der Kurve auf der die Fussspitze entlang läuft f(dx, dy, ddh) mit Übergabe an Ebene 2
3b Ebene: Bahnplanung Fusspitze: Rückführung der Fussspitze auf die Anfangsposition f(dx, dy, ddH)
4 Ebene: Bahnplanung Körper: Bewegung im Raum von Start zu Zielkoordinaten mit entsprechender Ausrichtung f(ddx, ddy, Teta, h)
5 Ebene: Bewegung im Raum: Erstellen von Zielsequenzen um finale Position zu erreichen.

Ebene 1 und 2 sind abgeschlossen, jetzt will ich 3 und dann 4 implementieren. Die höhere Ebenen geben die Vorgaben immer weiter an die unteren Ebenen. Später ist dann noch geplant, dass ein Gyro die Lage überwacht und die Werte an die Ebene 2 übergibt.
Ebene 5 wird später die Abstandssensoren auswerten und anhand von erkannten Hindernissen einen Weg ermitteln, der um diese Hindernisse herum führt. Diese Ziele werden an Ebene 4 übergeben, die daraus ableitet, wie sich der Körper bewegen muss, um die Ziele zu erreichen. In der Ebene 3 werden daraus die Schritte generiert für jedes Bein und an Ebene 2 übergeben. Diese muss dann aus der Lage des Körpers und den Schrittvorgaben die Position der Fußspitze berechnen, die es zu erreichen gilt. Diese Werte werden an die Ebene 1 übergeben, die daraus dann tatsächliche Servowinkel generiert.

Natürlich muss man das nicht so kompliziert und komplex aufbauen, man kann sich das Leben einfacher machen in dem man rotation und Bewegen unabhängig anlegt. Dann dreht sich der Roboter erst in die Richtung und läuft dann immer gerade aus, dreht sich wieder, läuft gerade aus und so weiter. So braucht man nur drehen und gerade aus laufen implementieren. Ebene 5 und 6 können mit einer Fernsteuerung vom Menschen übernommen werden.

In Ebene 6 stell ich mir vor, dass eine Zielpunkt auf einer Karte angegeben wird und dieser erreicht werden soll. Dazu überprüft der Hexa die Sensoren und läuft auf direktem Weg zum Zielpunkt, stößt er dabei auf ein Hindernis versucht er einen Weg außen rum zu finden. Optimaler weise erstellt er dabei noch eine Karte, auf der das Hindernis eingetragen wird. Ist nach umgehen des Hindernisses der Zielpunkt erreicht: Perfekt. Falls nicht versuch einen anderen Weg zu finden. In dieser oder noch höheren Ebenen kann der Roboter dann auch erkennen, ob z.B. ein Durchgang breit genug ist um ihn quer zu durchlaufen oder er sich erst auf längs drehen muss.

usw.


PS:
11.412.211.223.344.111 Ebene: Weltherrschaft!

[robin]

Die Lösung ist eigentlich ganz einfach, 12Divisionen und 5 Vergleiche.

Dein Roboter hat doch bestimmt eine Maximalgeschwindigkeit pro berechnungsschritt vorgegeben und bewegungsrichtung vorgegeben.
Also z.B. X,Y,Z maximal 5mm/Berechnung, alpha,beta,gamma je 5°/Berechnung.
Jetzt Teilst du deinen Zurückzulegenden Weg durch das Maximum der jeweiligen Bewegungsrichtung (temporär, der alte Wert wird weiterhin benötigt). Größter Teiler.
Danach bestimmst du das Maximum der Ergebnisse und Teilst deine Bewegungsrichtungen durch den zuvor bestimmten Teiler.

--> Dein delta, das du zurücklegen musst um eine gleichmäßige Bewegung zwischen A und B zu erreichen.

[HannoHupmann]

@robin, so einfach ist es leider nicht oder ich versteh deine knappe Erklärung einfach nicht.

Die Bewegung ist nicht von der Geschwindigkeit abhängig, die hat überhaupt nichts damit zu tun. Es geht um eine Strecke und nicht wie schnell die Strecke zurückgelegt wird.
Es gibt natürliche eine maximale Strecke die die Fussspitze zurück legen kann. Diese Strecke ist davon abhängig wie weit die Spitze vom Drehpunkt in der Hüfte entfernt ist und damit wie hoch der Körper des Hexas über den Boden gehalten werden soll. D.h. hier hat man es mit einer variablen Strecke zu tun.

Auch deine Erklärung beschreibt nicht, wie die Bewegung der Fussspitze als Ableitung der Gesamtbewegung des Roboters aussehen muss. Einfaches aufsummieren von dx, dy Schritten funktioniert leider nicht, solange nicht irgendwo vorgegeben ist wie dx und dy aussehen muss.

Zurück zum Problem:
Im Moment ist die Aufgabenstellung 4a und 4b zu implementieren. D.h. wie müssen die 6 individuellen Bahnkurven der Füße aussehen um alle Bewegungen des Hexas abzudecken. Also laufen in alle Richtungen + dabei drehen um jeden beliebigen Winkel oder um es weniger technisch auszudrücken: wie müssen die Bahnkurven aussehen um Walzer tanzen zu können!

[robin]

Warum willst du mit 6 verschiedenen Bahnkurven rechnen? Selbst für Geländegänge ist nur eine Manipulation von Z der einzelnen Beine nötig (in der Regel über Endschalter am Fuß gelöst).

In deiner Obersten Berechnungsebene (Ebene 4+) hast du ein starres Koordinaten System mit fester Ausrichtung im Raum, im prinzip eine Karte. Hier drauf bewegt sich dein Roboter als Vektor (Punkt mit Richtung/-en).
Den Sinn von ebene 3 versteh ich nicht, denn deine IK muss nur 2 Dinge kennen, die aktuelle Position und delta Werte für jede Richtung/Drehung um daraus die neuen Servowinkel zu errechnen.

So würde ich das machen:
5+ Ebene: Map erstellen, Kolisionserkennung, Autonomes Laufen im Raum über X verschiedene Punkte
4 Ebene: Bahnplanung Körper: Bewegung im Raum von Start zu Zielkoordinaten einer größeren Teilstecke P1 zu P2, danach P2 zu P3....
3 Ebene: Teilschritte aus Bahn von Ebene 4 Erzeugen in abhängigkeit von maximal geschwindigkeit.
2a Ebene: Inverse Kinematik: Position der Fussspitze im Raum bestimmt durch f(x,y,h)= alpha, beta gamma übergeben an die Ebene 1.
2b Ebene: Inverse Kinematik: Lage des Körpers, kippen um die Längs und die Querachse f(Q, L)=dh und Übergabe der daraus resultierenden Höhenänderung
1 Ebene: Servosignale Generieren

Machen wir mal ein kleines Beispiel:
Dein Roboter befindet sich im Koordinatensystem an Punkt P1=(0,0,0,0°) und soll über P2(10cm,10cm,0,60°) nach P3(20cm,10cm,0,60°) laufen, ob das ganze jetzt als Kurve oder Gerade ist, spielt erstmal keine Rolle. Das ist jetzt Ebene 5+ und gibt einen Weg vor, der abgearbeitet werden soll ähnlich einem GCode.

Ebene4 bearbeitet jetzt nur eine Zeile des "GCodes" gehe von P1 nach P2. Alle weiten Punkte sind für Ebene4 ersteinmal uninteressant.

Ebene3 arbeitet jetzt immer nur Teilstücke des Weges aus Ebene4 ab (man kann wohl Ebene 3 und 4 zu einer zusammenfassen). Die Größer der Teilstücke hängt von der Geschwindigkeit ab, mit der z.B. die Strecke zurückgelegt werden soll (schleichen, Trap, galopp) oder die als Maximum definiert ist (durch geschwindigkeit der Servos und Mechanik). Die Geschwindigkeitsangabe besteht aus einer Strecke pro berechnung und einem Winkel pro berechnung (als beispiel mal 10ms pro Berechnung). Sagen wir 5mm/Berechnung und 1°/Berechnung. Ausgehend von einer geraden zwischen P1 und P2 bedeutet das einen Abstand von ~141mm /5 = 28 Berechnungsschritte. Für den Winkel werden aber 60 benötigt. Hier kann man um einen gleichmäßigen gang zu ermöglichen und sich nicht 32 Berechnungen lang am ende zu drehen, die Geschwindigkeit anpassen. Also 141mm/60=2,35mm/Berechnung. Das wäre dann der Teilschritt der Bahnkurve und wird als deltaX,deltaY,...deltaalpha an die IK übergeben.

Ebene2: Inverse Kinematik und Kontrolle ob Bein zurückgesetzt werden muss.

Ebene1: Winkel in Zeit umrechnen und PPM-Signal erzeugen.

Das ganze lässt sich natürlich noch verfeinern und z.B. Beschleunigungsrampen einbauen. Ebene 2 könnte man mit Sicherheit auch noch mehrfach unterteilen z.B. mit Schwerpunktberechnung etc.

So würde ich das auf jedenfall machen, hoffe das ist jetzt etwas verständlicher, wie ich das gemeint habe.

[HannoHupmann]

Im Prinzip reden wir vom selben, bis auf die Tatsache mit der Geschwindigkeit. Eine Wegstrecke wird nun mal nicht in Geschwindigkeit gemessen sondern in Länge und auch ein Winkel lässt sich sehr gut in eine Länge umrechnen. Es geht auch nicht darum ob der Hexa schnell oder langsam den Weg zurück legt, zumal die Servos alle mit gleicher Geschwindigkeit laufen müssen d.h. ich kann keinen schneller oder langsamer laufen lasse. Grundsätzlich kann ich für alle Servos die Geschwindigkeit rauf setzen, dann wird er schneller in allen Servos oder eben langsamer für alle Servos.
Ein weiterer Punkt ist, dass man den Servos nur Signale geben kann, aber keine Rückmeldung bekommt wo sie sich tatsächlich befinden. Abgesehen davon ist es das Gleiche.

an Punkt P1=(0,0,0,0°) und soll über P2(10cm,10cm,0,60°) nach P3(20cm,10cm,0,60°) laufen, ob das ganze jetzt als Kurve oder Gerade ist, spielt erstmal keine Rolle.

Leider geht es genau darum!

Die Schwierigkeit liegt nicht in der übergeordneten Theorie, sondern z.B. darin wie die Mathematik aussehen muss um den Roboter z.B. zu drehen. Nun ist drehen um den Mittelpunkt noch recht einfach, aber drehen um einen beliebigen Punkt braucht eben 6 unterschiedliche Bahnkurven. Bei reinen bewegungen schräg oder gerade ist es deutlich einfacher. Hier mal die Berechung von meinem Phoenix² Projekt, die hatte noch eine feste Vorgabe für die Höhe h!


Heute Nachmittag habe ich mal versucht die beiden Linien auf denen sich die Beine bewegen werden zu überlagern. Da sich allerdings das Koordinatensystem dabei mit dreht ist es rechnerisch ziemlich aufwendig die ursprüngliche Weglinie im neuen Koordinatensystem darzustellen. Soviel Rechenpower hat mein µC vermutlich nicht.

[robin]

Wenn deine IK richtig implementiert ist, dann ist eine Kurve auch nur die länge eines Kreisbogens immer auf X addieren und der Winkel um den gedreht wird. Wichtig, damit es eine Kurve wird, ist das beide Werte gleichmäßig reduziert werden.

[robin]

Die Erklärung oben ist etwas dürftig, hatte wenig Zeit.

Nochmal zu der "Geschwindigkeit". Bei der Ansteuerung hast du eine Zeitkonstante, entweder deine Berechnung der IK oder das Generieren deiner Servo Signale (<20ms). Innerhalb dieser Zeit können sich deine Servos nur um x Grad bewegen oder anders formuliert deine Fußspitzen bzw.Torso x mm zurücklegen. Klar spielt es hier auch ein rolle wie weit die beine gespreizt sind, ich gehe bei meinen Berechnungen vorerst von einer festen maximal Geschwindigkeit aus, die in jeder Beinlage erreicht werden kann, da ich den entsprechenden Rechenschritt noch nicht implementiert habe.

Da dein Roboter aber vermutlich nicht immer mit maximaler Geschwindigkeit laufen soll, kannst du deiner IK auch einen kleineren Winkel als Maxima vorgeben -> Roboter wird langsamer, da weniger Bewegung in diesem festen Zeitintervall stattfindet. Der Servo dreht dadurch nicht langsamer, sondern es wird lediglich sein Weg begrenzt, den er pro Berechnungsschritt zurück legen darf.

Zu dem Problem des fehlenden Feedbacks: Deswegen muss das Limit so liegen, dass dieser Wert unter allen Umständen erreicht werden kann.

Wie schon gesagt, sollte das drehen um einen beliebigen Punkt keine Probleme mehr in Ebene 3 bereiten, da es nur noch die richtige Kombination von Übergabe werten in deine IK benötigt. Eine Dreh- und Bewegungsrichtung mit entsprechenden "Geschwindigkeiten"/Limits, denn sonst dreht er sich zB. zu schnell im Kreis und läuft dann nur noch in eine Richtung.

Ebene 3 produziert aus deiner vorgegeben Bahnkurve die der Roboter laufen soll dann sehr kleine (wenige mm) geraden mit einem Winkel relativ zum Roboter. Im Prinzip der Geschwindigkeits Vektor deines Roboters.

Ich versuche das morgen mal für ein besseres Verständnis in eine XY-Ebene auf zeichnen und krame dann noch meine IK-Berechnungen raus, falls gewünscht.

[HannoHupmann]

Ok dacht ich mir, wir reden vom gleichen nur unterschiedlich formuliert.

Aber kommen wir zurück zur Aufgabenstellung oder besser gesagt meinem aktuellen Problem:
Nochmal der Selbstversuch: zur Türe laufen und sich dabei in der Vorwärtsbewegung um die eigene Achse drehen. Diese Bewegung enthält, dass man ein paar Schritte rückwärts läuft, dann seitwärts dann wieder gerade aus. Soweit kann das jeder Mensch durchführen, da er seine Füße auf die entsprechenen Punkte am Boden stellt die Beine dazu passend bewegt.

Ein Hexabot kann diese Bewegung genauso ausführen, allerdings muss die Bewegung vorher berechnet werden. D.h. diese spezielle Bewegung gliedert sich in eine Bewegung Richtung Türe = translatorisch und eine Bewegung um die eigene Mittelachse = rotatorisch. Beide Bewegungen werden gleichzeitig ausgeführt und überlagern sich damit.

Beschreibt die Fußspitze von der minimal Position zur maximal Position eine Gerade auf dem Boden ist diese Bewegung nicht möglich, dann wäre es nur eine gerade Bewegung in eine Richtung. Keine Frage eine Kreis oder Kurvenbewegung lässt und muss hier in viele kleine Geradenstückchen unterteilt werden. Die Bewegung ist also eine abfolge von kleinen Geradenstückchen. Die Frage ist also, A: wie müssen die einzelnen Teilstücken der Bewegung von min zu max aussehen, damit sich der Körper nach vorn bewegt und gleichzeitig dreht und B: wie kann diese Bewegung rechnerisch dargestellt werden?

Vorüberlegung:
Zeichnet man sich beide Bewegungen auf, sieht man eine Gerade von min zu max (für die Bewegung nach vorn) und eine Tangente auf dem Kreisbogen um den Roboter zu drehen. Summiert man beide Bewegungen auf, erhält man eine Bewegung dazwischen die der gewünschten entsprechen sollte. Nur nach jeder kleinsten Teilbewegung des Roboters ändert sich seine Ausrichtung:

Ansatz 1: Roboter Koordinatensystem
Ich habe kein globales, ortsfestes Koordinatensystem sondern ein Roboterkoordinatensystem, welches fest auf dem Roboter ist (y- zeigt immer nach vorn). Bei einer translatorischen Bewegung ohne Drehung bleibt das Koordinatensystem wie es ist und wird im Raum verschoben (+5m zur Tür in Y-Richtung). Die Fussspitze beschreibt eine Gerade definiert durch einen Vektor V1( x=1, ymin = 5) zu V2(x=1 und ymax = . Bei einer Drehung entsteht ein Winkel zwischen dem ursprünglichen und dem Zielkoordinatensystem: Daraus folgt, dass die Bewegung V1 (1 5) und V2(1 im ersten Koordinatensystem in das neue Koordinatensystem übertragen werden muss und dort korrekt darzustellen ist. Meine Versuche die alte Bewegung von oben nach ins neue, gedrehte Koordinatensystem umzurechnen haben soviele Rechenschritte erzeugt, dass ich es aufgegeben habe, da es nicht praktikabel im Code umgesetzt werden kann.
Bei diesem Ansatz ist übrigens egal ob man nur ein infinitisimal kleines Wegstück betrachtet oder die ganze Bewegung von min zu max, denn die Umrechnung ins neue Koordinatensystem muss auch bei kleinen Wegstrecken korrekt sein.

Ansatz 2: Globales Koordinatensystem
Ein globales Koordinatensystem mit Ausrichtung Nord bleibt unverändert nur der Roboter in diesem Koordinatensystem verändert sich. Auch hier muss die Trajektorie laufen angepasst werden, da sich die Position des Roboters ändernt und damit auch die Abstände von Global X und Y. Es läuft immer darauf hinaus, dass die Positionsänderung des Roboters in der Bahnkurve der Füße berücksichtigt werden muss; was mit Trigonometrie nur sehr schwer zu beschreiben ist.

Ansatz 3: Bisher und bei Phoenix² implementiert
Zerlegen der Bewegung in zwei Teilbewegungen: Drehen um den Mittelpunkt und dann gerade aus laufen. Sehr trivial aber möglich, insbesondere sieht man an der Rechnung oben, dass ich damals schon "Drehen um einen beliebigen Punkt im Raum" implementiert habe. D.h. es muss gar nicht der Mittelpunkt sein um den sich der Roboter dreht, die daraus entstehenden Bahnkurven sind in meiner Berechnung dargestellt und wie man sieht auch nur Geraden, die in der Summe dann eine Kreisbewegung ergeben.

Meine Problemstellung ist also weniger, wie es übergeordnet aussieht, sondern mehr die reine, banale Mathematik um die Theorie der Bewegung in die Praxis der Bahnkurve einer Fußspitze umzusetzen. Es wird bei diesen komplexen Bewegungen immer auf eine individuelle Bahnkurve für jedes Bein hinaus laufen (was übrigens viel einfacher ist als man denkt), ist bei uns ja nicht anders wenn wir die oben beschriebene Bewegung ausführen.

[robin]

Also ist dein Problem eigentlich nur eine Simple Koordinatentransformation deiner delta werte aus dem Globalen Koordinatensystem in dein Roboter Koordinatensystem.

http://de.wikipedia.org/wiki/Koordinatentransformation

[HeXPloreR]

Hallo Hanno,

ich denke es gibt noch Denkfehler: Du benötigst auch ein globales Koordinatensystem um den Zielpunkt fest zu legen. Auch wen Du es nicht explizit vorgibst, ergibt es sich sobald Du irgendeinen Winkel für eine Drehung angibst und verarbeitest. Das bedeutet dann das Roboterkoordinatensystem sich mit dem Roboter dreht - es darf nicht fest stehen, denn sonst wäre es das Globale. Es spielt auch keine Rolle ob das Globale- und oder das Roboterkoordinatensystem nach Norden ausgerichtet sind. Wichtig ist hier nur der Bezug zueinander beim Start, an dem Punkt müssen sie sich decken - also Ursprung (0,0) haben. Dann entfernt sich der Roboter-Nullpunkt von Globalen-Nullpunkt. Das muss mitberechnet werden.
Es würde sicherlich ersteinmal die Koordinaten Vorgabe erleichtern wenn man es so macht. Stell Di hier bitte mal vor Du musst immer die neuen koordinaten selbst ausrechenen weil Dein Bot grade mal irgendwo 33° zu Norden steht. Dafür ist allein das Roboter-KooSy in Bezug auf Globale(Welt-KooSy) zuständig.

Jetzt musst du aber auch noch festlegen, welche Koordinaten Du bei einem Ziel angibst, die des Roboters oder der Welt. Und die bisherige Drehung und Entfernung in Bezug mit den Beiden setzen. Eine Karte kann möglicherweise ohne Kenntniss der Welt gebaut werden, aber sobald Du diese Karten auch als Bezugspunkte heranziehst benötigt sie den bezug zum WeltKoordinatensystem, nicht zum Roboterkoordinatensystem.

Meine Überlegung zu Deinem Problem: Ein Vektor wird von einem Fuß abgefahren (Schub), der Vektor wird mit dem aktuelle Drehwinkel gedreht. Der Vektor nähert sich jetzt immer mehr einer Bewegungsgrenze an, wo demnächst ein Schritt ansteht. Diesen neuen Schrittpunkt setzt man wieder auf den gleichen Schrittpunkt wie vorher im Roboter-Koo-Sy (das ...-Koo-Sy ist jetzt mein wort ), aber auch nur wenn die (Dreh)-Bewegung insgesamt gleichmässig ist - also der Drehwinkel sich nicht geändert hat. Auch eine Neuberechnung schadet hier wohl dennoch nicht.
Eine Änderung der Position einen Fußes kann nur über den Robotermittelpunkt passieren: Der Roboter dreht sich und dadurch ändert sich ja auch die Hypotenuse ziwschen Fuss und Mittelpunkt. Das erscheint mir eine einfache Sinus/Cosinus Rechnung zu sein, wobei der Vektor mitgedreht werden und der nächste Fußpunkt darauf liegen muss. Und jenachdem ob man sich in einer Schub- oder ein Schrittphase befindet entsprechend die Richtnung der Bewegung in Koordinaten für dei Füße ausgedrück werden muss.

ich bin kein Mathematiker, ein konkrete Rechnung kann und werde ich nicht liefern, vielleicht wenn ich die Lösung auch programmiert bekommen habe.
Ich denke auch es so ziemlich alles dazu gesagt worden.

EDIT: Ich möchte auch nochmal einen Link/PDF beisteuern.