Quadruped/Hexpod - fortgeschrittene Kinematik - Ansatz gesucht

Hallo!

Leider habe ich keine brauchbaren Suchergebnisse hier im Forum und im WWW gefunden - mich beschäfftigt die fortgeschrittene Kinematik für 4, 6 oder 8 Beinige Roboter.


Zu meinem Stand:
Ich habe grade meinen Quadruped mechanisch/elektrisch fertiggestellt und bin fleißig am programmieren - so habe ich zunächst einzelne Sequenzen für das Vorwärts, Rückwärts, Seitwärts Laufen sowie für das Drehen geschrieben. Diese funktionieren für sich alleine sehr stabil!

Grundlage hierfür ist, dass alle Beine jeweils um 25 % im Zylkus versetzt laufen: 3/4 der Bewegung ist das Vorwärtsbewegen und 1/4 zum Zurücksetzten des jeweiligen Beines. Hinzu kommt eine Schwerpunktkompensation indem der Roboter um seinen imaginären Mittelpunkt kreiselt so, dass der Schwerpunkt immer im Dreieck der 3 am Boden befindlichen Beine liegt.

Nun konnte ich den Roboter per WSAD komfortabel steuern - aber es störte mich, sobald ich die Richtung wechselte, dass der Roboter einen "Sprung" in der Bewegung machte da der Übergang der Zyklen nicht vorhanden (möglich) war.

Deshalb habe ich eine neue Funktion für die Bewegung geschrieben - hier habe ich alle Bewegungen kombiniert (ein kombinierter Zyklus für alle Bewegungsmöglichkeiten):
Die Beine können damit unabhängig, in jedem beliebigen Winkel, von der Blickrichtung des Roboters bewegen - das heißt z.B. der Roboter schaut geradeaus während sich die Beine diagonal nach hinten Links bewegen. Das ganze schaut auch sehr gut aus! (Ich habe mir ein Programm geschrieben, dass es erlaubt dynamisch alle Werte zu ändern wie Höhe des Toros, Schritthöhe, Schrittweite, Schnelligkeit, Gewichtsausgleich etc....)

Danach habe ich die Drehbewegung dazu überlagert - so kann der Roboter gleichzeit laufen, während er sich dabei auch drehen kann.
Das funktioniert ebenfalls sehr gut .... in die eine Richtung!
Das Problem: die Beine führen ihren Zyklus immer im Uhrzeigersinn aus damit alle Bewegungen synchron und übergangslos (weich) sind. Wenn der Roboter sich nun nach Rechts dreht und ein Bein anhebt/zurücksetzt ist der Schwerpunkt automatisch innerhalb der 3 stehenden Beine. Der Roboter dreht sich stabil.
Dreht er aber nun nach Links hebt immer das Bein an, welches das Dreieck des Schwerpunktes "trägt" - der Roboter kippt!
Auch die Schwerpunkt-Kompensation hilft hier kaum/nicht weiter - da da Gewicht soweit verlagert werden müsste, dass andere Bewegungen blockiert werden würden. (Durch den eingeschränkten Bewegungsraum, da der Robotertorso sich zu stark in diesen neigt und die Beine damit in ihrer Freiheit begrenzt)

Hier würde es nur helfen, die Reihenfolge der Bein-Zyklen entgegengesetzt des Uhrzeigersinns zu setzten - das würde aber das ganze Prinzip der weichen Bewegungen kippen da eine Richtunsgumkehr der Reihenfolge nur im Stillstand möglich wäre - aber auch während des Laufens möglich sein soll!

An für sich traue ich mir zu, dass ich abgesehen von diesem Problem im stande bin, Bewegungen zu gestalten, wie man sie in vielen Youtube-Videos sieht: z.B. den Torso neigeen, rollen oder gieren und ähniches....

Auch wenn dieses Problem sehr gering scheint, bin ich davon überzeugt, dass ich es innerhalb dieser Bewegungssteuerung nicht gelöst bekomme.

Abhilfe:
Ich habe schon vor dieser Problematik nach Informationen zur unabhängigen Bewegungssteuerung der einzelnen Beine gesucht - so sieht man öfters Videos zu Quadropoden oder Hexas, die ihren Boden abtasten, und entsprechend der ermittelten Höhe weiterlaufen. Die Beine aggieren teilweise unabhängig!

Zu diesem Thema suche ich nun nach Ansatzmöglichkeiten, wie ich es schaffe, die Zyklen der einzelnen Beine teilweise unabhängig voneinander zu gestalten, und trotzdem eine Reihenfolge einzuhalten und den Gewichtsausgleich beizubehalten.

Wie gestaltet man das am besten?

Ich habe schon an eine Art Prioritätensystem gedacht: die Beine bewegen sich unabhängig in einem zyklusähnlichem Bewegungsablauf und führen einen Abgleich der Priorität aus, welchem Bein es nun erlaubt ist, einen Schritt vorwärts zu machen. Die Schwerpunktkompensation würde sich dann an diesen Prioritäten orientieren und sich dementsprechend ausrichten....
Was haltet ihr von diesem Ansatz - ist sowas praktikabel - oder führt das zum absoluten Kaos?

Kann mir hier vielleicht jemand eine Seite nennen wo ich mich entsprechend belesen kann - oder nützliche Ratschläge geben?

Anbei: Ich möchte hier aber NICHT über meinen Code disskutieren und suche auch keinen fertigen Code. Ich suche die Möglichkeit oder den Ansatz das Problem selber zu lösen und dabei dazuzulernen. Das ganze soll hier möglichst Theoretisch bleiben...

Gruß Erik

[Bemerkung] die Berechnung der Winkel/Beinpositionen bleibt hier außen vor - die Funktion ist bereits fertig

Das es mit Zyklen nicht klappt, ist schon mal die erste Erkenntnis. Zumindest bei einem Quadruped, bei einem Hexa sieht das ganze anders aus, denn hier hat man weniger Schwerpunkt Probleme und kann Zyklisch fahren, deswegen ist der Titel etwas verwirrend.

Was du auch richtig erkannt hast, ist dass du eine Korrektur benötigst. Denn einfach nur ein Bein heben, dass kein Kippen des Roboters zur Folge hat geht auch nicht, das sonst immer nur das selbe Bein angehoben wird.

Du benötigst als mehrere Funktionen:
- Welches Bein kann gehoben werden (so, das es kein Kippen zur Folge hat)
- Welches Bein muss gehoben werden (Das, dass unter Berücksichtigung der Bewegungsrichtung am Weitesten von einem Nullpunkt entfernt ist und gegen einen Grenzwert läuft)

Diese beiden Funktionen geben dir dann je eine Priorität der Beine an, eine Liste mit einem Wert für jedes Bein.
Sagen dir beide Funktionen, dass das gleiche Bein angehoben werden muss/soll ist alles klar und dieses wird neu gesetzt.
Bekommst du unterschiedliche Beine ausgegeben, musst du erkennen, welches das wichtigste ist und deine Schwerpunkt Kompensation durchführen.

So würde ich es zumindest machen, aber KP, ob das so funktioniert ist erstmal nur eine Überlegung.
Wo man so etwas nachlesen kann, wüsste ich aber auch zu gerne. Da bei mir demnächst das gleiche ansteht :D

Also ich habe mir gestern ordentlich den Kopf zerbrochen und kam letztendlich zu folgenden Erkenntnissen:

Ich habe den Roboter mal 2D in mehreren Beinpositionen gezeichnet und den Schwerpunkt jeweils ermittelt. Korregiert (zurücksetzten) man die Beine mit der optimalen Schwerpunktentlastung stellt sich automatisch eine brauchbare Reihenfolge der anzuhebenden Beine ein.
Außerdem kann man die Schwerpunktlage durch 2 Geraden ermitteln: die, die die beiden gegenüberliegenden Beinberührpunkte (durch den Mittelpunkt des Roboters) verbindet und eine Gerade die entweder gleich, oder um 90° versetzt zur Roboterorientierung ist.

Dann habe ich mal ein kleines Programm mit 2 Regeln zur Simulation geschrieben:
1. Regel: wenn ein Bein am Ende seines erreichbaren Raumes ist muss es vorgesetzt/angehoben werden
2. Regel: wird gerade ein Bein angehoben und ein Bein erreicht die Endlage muss die Geschwindigkeit solange gedrosselt werden, bis dieses Bein angehoben werden kann

Bereits nach 3 "imaginären Schritten" stellte sich eine flüssige (konstante) Bewegung ein.
Die Regeln würde ich dann damit modifizieren, dass auch weitere Einflüsse wie die oben genannte Schwerpunkt-Lage mit eingehen. Die Schwerpunkt kompensation würde ich dann vielleicht nur unterstützend gestalten - in der Hoffnung, dass das ausreicht...

Dummerweise sind mir vorgestern und gestern 2 Motoren verreckt .. die kleinen Ritzel sind abgeschert. (Wer billig kauft kauf 2 mal)
Ohne das reale Objekt tue ich mich ein bisschen schwer das ganze programmiertechnisch umzusetzten - ich hoffe morgen kommen die Ersatzteile...

Ich wollte nochmal ein kleines Update leisten.

Ich habe mir jetzt in Visual C# ein Simulationsprogramm geschrieben und mache damit gute Fortschritte.
Das ganze lasse ich mir zunächst erst nur grafisch anzeigen und erst wenn es passt wird das Programm auf den Roboter übertragen/üebrsetzt.

Mittlerweile habe ich die Erkennung der Prioritäten soweit, dass die Schwerpunkt-Kompensation relativ gering arbeiten muss:
Hierfür verwende ich bis jetzt folgende Prioräten (ähnlich wie es robin empfohlen hat)

- den optimalen Schwerpunkt: gegeben durch den Schnittpunkt 2er Geraden der gegenüberliegenden Beine - ist dieser Schnittpunkt im Quadranten des jeweiligen Beines so erhöht sich damit dessen Priorität vorgesetzt zu werden, da der Roboter stabil auf den anderen 3 stehen kann

- die zurückgelegte Wegstrecke des Beins seid dem Vorsetzten (berücksichtigt auch, dass alle Beine regelmäßig vorgesetzt werden)

diese Prioriäten der Beine werden dann Verglichen, und das Bein welches es am nötigsten hat darf vorgesetzt werden.
Die Geschwindigkeitsbegrenzung bei Nährung an die Endlage habe ich erstmal entfernt - legt man alles gut aus wird das kaum/nicht benötigt.
Zusätzlich erlaubt mir das Simualtionsprogramm die Wichtung der Prioritäten dynamisch zu ändern.

Ich bin gespannt wie das später auf dem Roboter läuft - einziges Manko (?!) Manchmal werden einzelne Beine sehr vorzeitig vorgesetzt, obwohl es nocht nicht notwendig wäre...

Jetzt muss ich das reine Drehen, sowie später die (dynamsiche) Gewichtskompensation noch implementieren...