Quadruped/Hexpod - fortgeschrittene Kinematik - Ansatz gesucht

[robin]

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

[erik_wolfram]

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

[erik_wolfram]

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