Zitat Zitat von HannoHupmann Beitrag anzeigen
Hier gleich die Antwort auf die Frage von HexPlorer: Gibt man z.B. vor: "Bleib auf der Stelle stehen aber dreh dich um 180°" würde ich keinen einzigen Schritt nach vorn oder hinten brauchen, aber eben x-Schritte für die Drehung. Gleiches gilt für: "Lauf 10 Schritte gerade nach vorn, aber ohne Drehung" wieder hätten wir einmal 10 Schritte und einmal 0 Schritte. Die Abfrage IF/ELSE soll einfach die Anzahl der Schritte auswählen, die größer ist und dann ausführen. Im ersten Fall würden sich dx und dy = 0 und damit keinen Beitrag zur Bewegung der Fusspitze haben. Nur Winkel = 180° wird sich auswirken.

Zu den Schritten an sich:
Grundsätzlich bevorzuge ich ein 5x1, da es deutlich stabiler ist als 3x3 wenn auch langsamer. Vielleicht implementiere ich auch, dass bei geraden Strecken ohne Rotation ein 3x3 erlaubt ist. Für den Anfang ist 5x1 einfacher.
Also wenn schon jeweils ein Bewegungsschema für reine Geradeaus- bzw. Drehbewegung vorhanden ist, würde ich für eine geschmeidige Fortbewegung eine einfache Überlagerung versuchen:
Für die Drehung bewegen sich vermutlich die einen Beine vorwärts und die anderen Rückwärts - es gibt also quasi eine Differenz in den Bewegungsvorgaben für die Beine. Da zur Fortbewegung die Vorwärtsbewegung evtl. schon ausgeschöpft ist, kann man diese Differenz bei Überlagerung also nur durch Verlangsamung der "Kurveninneren" Beine erreichen. Der erzielbare Betrag verringert (halbiert?) sich dadurch also.
Wenn man jetzt eine Bahnplanung hat, sollten die auszuführenden translatorischen und rotatorischen Operationen bekannt sein. Dann die Bewegungsvorgaben einzeln berechnen, die für die Rotation noch durch Faktor 2 (?; s.o.) oder etwas höher, für glatteren Ablauf, Teilen, zur Translation addieren und das ganze ausführen lassen.

Zitat Zitat von HannoHupmann Beitrag anzeigen
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
Hier scheinen sich für mich auch wieder (übergeordnete) Bahnplanung und "konkrete" Bewegungsplanung des Bots (Schrittfolge) zu vermischen. Die Berechnung über Kreissegmente dürfte außerdem recht aufwendig werden, oder?

Zitat Zitat von HannoHupmann Beitrag anzeigen
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.
Das dürfte die einfachste und flexibelste Umsetzung sein.
Ähnelt wohl auch meinem oben beschriebenen Ansatz. Nur würd ichs nach der getrennten Berechnung, dann aber überlagern.

Das Türproblem ist allerdings auch schon recht speziell ist finde ich. Dadurch das zu der geraden Hauptrichtung der Bewegung trotzdem eine Drehung kommen soll hast Du ja unterwegs zwischen "straightforward" und "90° seitlich" quasi beliebige "Strafing-Winkel" zu bewältigen, um in der Hauptrichtung auch noch vorwärts zu kommen. Die müssten wahrscheinlich vorher erstmal "eintrainiert" werden.