.: Vinculum :. - Hexabot

Hallo Hanno,
diesen Artikel [1] finde ich sehr nützlich und verständlich.

Gruß
Georg

[1] http://freespace.virgin.net/hugo.elias/models/m_ik.htm

Interessanter Ansatz, das ganze mit Kräften zu berechnen, statt mit Position.

Allerdings bin ich schon ein bischen weiter. Im Moment geht es mir darum die Target Positionen zu finden. Hier habe ich heute sehr viel gerechnet und in excel getestet jetzt habe ich die Berechnungen für die einzelnen Fusskurven-Segemente soweit fertig. Morgen muss daraus noch eine Abfolge werden. Ich bin noch nicht sicher ob es dann so funktioniert wie geplant, aber das werde ich erst sehen, wenn ich alles im Spin implementiert habe.

So die Berechnung ist nun erst mal fertig und komplett im Excel programmiert als erster Test, denn dort kann ich mir die Positionen in einem Diagramm anzeigen lassen und meine Formeln prüfen.

Nächster Schritt ist es die ganze Mathematik die dabei entstanden ist in Spin zu programmieren und dann hoffe ich, dass die ersten Tests erfolgreich sein werden.

Gerade habe ich noch heraus gefunden, dass ich zwischen den Geschwindigkeiten 3:3, 4:2, 5:1 relativ leicht durch das Ändern eines Parameters umschalten kann, damit kann der Roboter in allen Geschwindigkeiten laufen :cool:

Zitat:

---

Zitat von HannoHupmann

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

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

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.

Zitat:

---

Für die Drehung bewegen sich vermutlich die einen Beine vorwärts und die anderen Rückwärts

---

Gilt nur für Drehungen bei denen der Drehpunkt innerhalb des Roboters liegt. Für Drehpunkt außerhalb bewegen sich die Beine in die gleiche Richtung. Der Radius bzw. die Länge der Bogensehne ändert sich. Das hatte ich schon bei meinem Phoenix² implementiert. Lässt sich allerdings sehr leicht errechnen, wenn man für die Drehung die Vorgaben v,w (die x und y Koordinaten des Drehpunkts) und den Winkel teta angibt um wie viel Grad der Roboter sich um den Punkt drehen soll. Bei v,w = 0, gilt was du sagst, dann bewegt sich eine Seite nach vorn und die Andere zurück. Bei v = 20 und w = 0, wäre es eben eine Bewegung auf dem Kreisradius. Für jedes Bein wird dann ein eigenes Bogensegment berechnet mit der dazugehörigen Tangente und einer spezifische Länge (berücksichtigen des Abstands vom Drehpunkt).

Mittlerweile habe ich die Aufgabenstellung sehr weit lösen können. Die Rotatorische Bewegung wird wie oben berechnet und durch die Translatorische überlagert. Daraus wird die Schrittlänge und die Bahnkurve berechnet für jedes Bein berechnet. Am Ende der Bahnkurve erfolgt die Rückführung zur Startposition, mit einer kleinen Trajektorie damit es sanfter aussieht. Wenn sich alle Beine einmal über die Schrittlänge bewegt haben ist ein Voll_Schritt fertig. Aus Teta und dem maximal möglichen Winkel der pro VollSchritt gedreht werden kann ergibt sich die Anzahl der Voll-Schritte für drehen und bei translation nehme ich einfach x²+y² = Distanz² und Teile die Distanz durch die kleinste Schrittlänge.

Weitere Features die bereits implementiert sind: Ich kann drei Geschwindigkeiten wählen ob ich nun 3:3, 4:2, oder 5:1 bewegen möchte (Anzahl der Beine am Boden : Beine in der Luft) die Berechnung ermittelt dann automatisch die korrekten Punkte auf der Bahnkurve und natürlich wie schnell sich die Motoren generell drehen sollen. Natürlich auch kippen und neigen wird berücksichtigt.
Das lässt sich alles mit genügend Mathematik erschlagen und aktuell bin ich dabei die Formeln im Code darzustellen und dann wird es vermutlich ziemlich viel debugging geben.

Ob diese Berechnung schon für mein Tür-Problem reicht kann ich schwer sagen, im Prinzip ja, aber vielleicht muss ich auch noch eine übergeordnete Ebene programmieren.

So der Code ist geschrieben, aber funktioniert natürlich noch nicht, gestern habe ich es nur noch geschafft die Translation zu debuggen.

Anderes Thema: Servos
Leider ist ein weiterer Servo (BMS-705MG) ausgefallen und ich vermute einer steht kurz davor, aber der Reihe nach.
1) Servo lässt sich gar nicht mehr ansteuern, wenn er manuell bewegt wird, geht er sehr schwergängig.
2) Servo wird noch angesteuert aber dreht sich auch schon deutlich schwerer als die übrigen.

Der letzte Servo (BMS660 DMG + HS 52) der ausgefallen ist hatte deutliche Brandspuren auf der Steuerplatine. Motor und Getriebe haben noch wunderbar funktioniert.
Leider habe ich noch keine Ahnung was diesen "Tod" verursacht, denn noch bewegen sich die Beine nur in der Luft, d.h. ohne Belastung.
Kann es einfach an der Chinaproduktion liegen?
EDIT: Gerade bei Hobbykin.com gelesen: "Der gute erste Eindruck (Getriebespiel, Rueckstellgenauigkeit usw.) steht einer sehr geringen Lebensdauer gegenber. Die Motorbuersten sind stark unterdimensioniert und brennen schnell ab, was zum Ausfall des Servos führt. ... Betroffen sind auch BMS 706, 760, 761 mit identischem Motor !!"Frage ist nun, kann man das irgendwie verbessern/optimieren?


Dummerweise ist meine ganze Konstruktion auf diese beiden Abmessungen abgestimmt, so dass ich die Servos nicht einfach mit einer anderen Marke austauschen kann.

Ds klingt nicht gut, da bleibt dir ja fast nur die möglichkeit einen ersatzmotor zu suchen. Die frage ist dann aber ob der dann auch die gleiche kraft/Geschwindigkeit liefern wird.

Hast du mal die Maße der Motoren? Vllt. findet man ja was.

BMS-705MG: Dimensions: 42 x 21.5 x 22 mm
Bild hier  

BMS660 DMG: Dimensions: 40.5 x 20 x 42mm
Anhang 26458

Hab eigentlich die internen motoren gemeint, nicht die Servos an sich ;)

Pu da muss ich erst kucken, hab den letzten Ausfall zerlegt da kann ich ein Bild von machen.