Druckbare Version
Man könnte ja auch fein anschleifen. Spart das rupfen, obs natürlich den Aufwand nennenswert verbessert wäre fraglich.Zitat:
Zitat von HannoHupmann
OT: Womit strahlst Du denn die Teile? Mit so nem Aufsatz für den Haus- Hof und Garagenkompressor oder hast was Profesionelleres?
Bei ersterem tät mich interessieren, ob sichs lohnt das anzuschaffen. Vor allem zwecks Sauerei mit dem Sand und Auffangen etc.
Gruß Ryoken
Nein ich müsste sie trotzdem raus rupfen weil die unter den Abdeckungen versteckt sind. Letztere sind in einer professionellen Box gestrahlt, habe ich in der Arbeit gemacht.
Jemand am Mitlesen der sich als SPIN-Experte outen will? Ich bin gerade dabei meinem Propeller Chip die IK zu verklickern und ich habe in kleines Cog Problem. Bzw. ich wüßte gerne ob ich der Float32Full auch spezifische Cogs zuweisen kann.
Für alle nicht Experten: Die Idee von den 8 Cogs des µC jedem Bein einen zur Verfügung zu stellen scheitert daran, dass die Mathe Funktion auch zwei haben will.
So gerade wird die PowerControll Platine fertig und wieder geht es an das leidige Thema einen Hersteller für die Platinen zu finden. Entweder muss ich gleich 100 Stück abnehmen oder die Qualität ist bescheiden oder der Preis völlig überzogen.
Allerdings muss ich jetzt erst noch die richtigen Abmessungen für diese winzigen SMD ICs herausfinden.
Sinn der Übung:
Eine Platinge die den Eingangsstrom und die Eingangsspannung vom Akku überwacht und mir per i²c zur Verfügung stellt. Da der Chip aber mit 5V arbeitet brauch ich auf der Platine auch gleich noch einen Konverter von 5V auf 3,3V. Die Bauteile sind schon all da, nur die Platine fehlt noch...
Hallo Hanno,
ich lasse meine Platinen nach wie vor von Bilex in Bulgarien machen. Du musst definitiv keine 100 Stück abnehmen, die Platinen sind günstig und die Qualität ist in der Regel in Ordnung. Letzteres bedeutet, dass es bei mir hin und wieder durchaus mal Probleme mit der Qualität gab, dem wurde dann aber unbürokratisch mit Ersatz oder Preisnachlass begegnet. Mittlerweile gibt es auch viele chinesische Anbieter, bisher habe ich mich aber noch dazu durchgerungen, denen mal eine Chance zu geben.
So sehen die Platinen von Bilex beispielsweise aus:
Anhang 26201 Anhang 26202
Gruß
Malte
Muss ich mal mit meinem Design ausprobieren. Ich bin aber noch am Feintuning der SMD-Chip-Abmessungen. Irgendwie passen die Geometrien da nicht so ganz zu meinen Bauteilen.
Sind leider im Urlaub die Jungs von Bilex, wir eh knifflig mit diesen kleinen Chips zurecht zu kommen.
Anhang 26212
ist halt leider mit den beiden Chips für Power und i²c so ein bisschen knifflig.
Anhang 26261
Scheinwerfer front, Aufnahme mit 10% Leistung.
So nachdem es jetzt einige Tage ruhiger war um meinen Hexa und ihr vermutlich heute schon im Fehlschlag-Thread gelesen habt, dass mir ein Servo abgeraucht ist, gibt es nun News (wie man auf altbayrisch so schön sagt).
1) Der Servo ist komplett hin, da hilft nur noch austauschen, daher bewegt sich Bein B auch so komisch.
2) Die inverse Kinematik ist nun vollständig implementiert.
Was bedeutet das?
Ich muss die Winkel der Servos nicht mehr ausrechnen sondern sie werden berechnet aus folgenden Größen:
Translatorisch:
dx - die x-Richtung der Fussspitze gemessen von der Hüfte
dy - die y-Richtung der Fussspitze auch gemessen von der Hüfte.
--> über den Atan2 wird daraus der Winkel für die Hüfte!
--> Mit der Höhe h werden daraus die Winkel für Schulter und Fuss
Rotatorisch:
hbasis - die Grundhöhe des Hexas über dem Tisch
Winkel Querachse -Rotation um die x-Achse also wie viel der Körper sich nach vorn oder hinten neigen soll
Winkel Längsachse - Rotation um die y-Achse, also wie viel der Körper sich links oder recht neigt.
wy - Wo sich der Drehpunkt für Q befindet auf der y Achse
wx - Wo sich der Drehpunkt für L befindet auf der x Achse
Was heißt das jetzt?
Aus den beiden Winkeln Q und L mit ihrer Position lässt sich der Körper beliebig kippen um die beiden Achsen x und y (drehen um z würde über die dx und dy werte gehen), wie bei einem Flugzeug. Durch die Parameter wx und wy lässt sich der Drehpunkt an eine beliebige Stelle auf dem Roboter (oder auch außerhalb) verschieben und so um jeden Punkt kippen.
Ich verstehs immer noch nicht?
Dann schaut euch das Video an:
http://www.youtube.com/watch?v=N2dyZ...ature=youtu.be
Wie gesagt Bein B (das Mittlere rechts) hat einen defekten Schulterservo.
Die Kunst daran ist zum einen die reinen Formeln in Mathe aufzustellen, hier reicht aber Sinus, Tangens und Cosinus Wissen aus. Danach muss man diese Formeln schön im Programm umsetzen, was deutlich aufwendiger ist, da hier die Syntax des Programms zum tragen kommt:
Beispiel für Bein A
Hier hilft es die Berechnung in Excel aufzubauen mit einer grafischen Darstellung zu prüfen ob das überhaupt funktionieren kann bzw. was bei den Werten herauskommen muss. Leider habe ich keine Möglichkeit die Werte nach der Berechnung am Hexa ausgeben zu lassen, da er kein Display oder eine Schnittstelle dafür hat.Code:dQ := math.Sin(math.Radians(wQ))
dL := math.Sin(math.Radians(wL))
dhAF := math.FMul(dQ, math.FSub(+230.0, -wy))
dhABC := math.FMul(dL, math.FSub(-110.0, -wx))
hA := math.FAdd(hBasis, dhAF)
'~~~~~ BERECHNUNG SERVOWINKEL ALPHA GAMMA PHI
'----- Länge von Bein A ----
ca_2 := math.FAdd(math.FMul(hA, hA), math.FMul(rA,rA))
ca := math.FSqr(ca_2)
'----- Winkel von Hüfte A0 ----
phi := math.Degrees(math.Atan2(xA, yA))
phi := math.FAdd(math.FMul(math.FSub(phi, 5.0), 8.0), 809.0)
Aziel[0] := math.FRound(phi)
Aziel[0] := Aziel[0] +0
'----- Winkel Schulter A1 ----
alpha_P := math.ATan(math.FDiv(rA, hA))
alpha_PP := math.ACos(math.FDiv(math.FAdd(aa_m_bb, ca_2), math.FMul(ax2, ca)))
alpha := math.Degrees(math.FAdd(alpha_P, alpha_PP) )
Aziel[1] := math.FRound(math.FAdd(math.FMul(math.FSub(alpha, 5.0), 8.0),809.0))
Aziel[1] := Aziel[1] - 60
'----- Winkel Fuss A2 ----
gamma := math.ACos(math.FDiv(math.FSub(aa_p_bb, ca_2), abx2))
gamma := math.Degrees(gamma)
gamma := math.FAdd(math.FMul(math.FSub(gamma, 5.0), 8.0), 809.0)
Aziel[2] := math.FSub(2910, math.FRound(gamma))
Aziel[2] := Aziel[2] +80
Noch Fragen?
Hat jemand eine Idee wie man die Bahnkurve bzw. Trajektorie implementiert?
Welche Bahnkurve meinst du jetzt? Das Vorranheben des Beines oder meinst du allgemein?
Das was du meinst ist die inverse Kinematik, die ist nun nahezu vollständig implementiert. Was ich jetzt suche ist die sogenannte Bahnkurve. D.h. die Trajektorie bei der sich der Roboter von A nach B bewegt. Also von einem Ausgangspunkt zu einem Zielpunkt und diesen Weg muss ich irgendwie in der Mathematik abbilden.
- - - Aktualisiert - - -
Das was du meinst ist die inverse Kinematik, die ist nun nahezu vollständig implementiert. Was ich jetzt suche ist die sogenannte Bahnkurve. D.h. die Trajektorie bei der sich der Roboter von A nach B bewegt. Also von einem Ausgangspunkt zu einem Zielpunkt und diesen Weg muss ich irgendwie in der Mathematik abbilden.
Ich würde es versuchen so zu lösen das man den Anfangspunkt und den Zielpunkt (A-Z) als Variablen, dann den Weg dazwischen in die kleinste Einheit zerlegen die die Beine sich bewegen können und dann solange auf den Anfangstpunkt aufaddieren bis man den Zielpunkt erreicht hat. Sollte auch für Koordinaten funktinieren. Habe ich selbst sovor, aber noch nicht umgesetzt. Daher ist es erstmal nur ne Idee.
Meine Gedanken gehen in eine ähnliche Richtung. D.h. ich habe eine Aktuelle Ist Position definiert durch x=0, y=0, und Drehwinkel alpha = 0° und eine Zielposition mit z.B. x = 150cm, y = 150cm, alpha 45°. Damit müsste der Roboter dann 150cm nach vorn und 150cm nach rechts laufen (translatorisch) und dabei die Orientierung des Körpers um 45° drehen (rotatorisch). Soweit so gut. Einziges Problem was ich bisher noch habe ist, wie ich die Wegstrecke sinnvoll in Schritte unterteile, denn die Zielpositionen können unterschiedlich weit entfernt sein und daher in variablen Anzahl von Schritten erreicht werden, die Anzahl gilt es irgendwie sinnvoll zu bestimmen.
Mir fehlt es an Erfahrung in diesem Bereich aber manchmal können Ideen von "Unwissenden" ja ein Anstoß für die eigene Lösung sein ;)
Als Bezug würde ich das mittlere Beinpaar wählen, um die Bewegungen des vorderen, bzw. hinteren, Beinpaares davon abzuleiten.
Den Bogen, den das kurvenäußere Bein zurücklegt, würde ich in Bogensehnen unterteilen. Die Länge dieser Sehnen könnte die maximal zurücklegbare Strecke des Beins bei einer Bewegung sein, aber kleiner um auf den Untergrund angepasst eine bessere Mobilität zu erziehlen (auf ebener Fläche sind keine Steine oder Löcher zu erwarten).
Die Länge der ermittelten Sehnen würde ich im Verhältnis äußere Kurvenbahn zu innerer Kurvenbahn verkürzen um mit der gleichen Anzahl Schritten den benötigten Weg zurück zu legen. Wenn ein Mensch um eine Kurve läuft hebt er ja auch immer abwechselnd die Füße und macht unterschiedlich große Schritte.
Auf Basis dieser Bewegungen müsste man dann die Bewegungen der verbleibenden vier Beine errechnen. Ich denke, es sollen immer drei Beine Bodenkontakt haben (Mitte links + Vorne/Hinten Rechts oder umgekehrt)
Hallo Arkon,
was du beschreibst - und auch völlig richtig - ist die weiter Führung der Inversen Kinematik zu einer einfachen Bein-Trajektorie. Was allerdings noch fehlt ist die übergeordnete Bahnplanung oder um es weniger technisch auszudrücken: der Weg.
Hier mal meine Lösung, wie ich mir das Vorstelle:
Anhang 26426
Nur leider wird er bei einer überlagerten translatorischen und rotatorischen Bewegung keine Kurve laufen, sondern einfach schräg mit einer entsprechenden Drehung des Körpers.
Also vereinfacht die Bahn, die ein Punkt(z.B. Schwerpunkt oder Drehpunkt) auf der Basis zwischen Start und Ziel verfolgen soll?
Dann müsste doch die Distanz nicht als Gerade (Pythagoras -> Gleichschenklige Weiber, her damit!) sondern als Bogen berechnet werden. Für die Berechnung eines Punktes auf einer Kreisbahn wäre das entsprechend Bild hier Die Bogenlänge geteilt durch den maximal zurücklegbaren Weg pro Schritt würde dann die Anzahl der benötigten Schritte ergeben.
Sollte ich nur Blödsinn oder unnützes Zeug schreiben wink doch bitte kurz mit dem Zaunpfahl. Will nicht mit unqualifizierten Aussagen nerven ;)
Ich denke auch der Lösungsanstz ist der Richtige, nur sollte man vermutlich eine Kreisbogenbahn, wenn man Kurven läuft, in viele kleiner Punkte zerteilen... und diese Punkte dann mit Geraden verbinden, damit man die Steigung einfach herausbekommt.
Man kann natürlich auch den Kreisbogen mit Sinus/Cosinus in verschiedenn (aktueller) Winkeln bearbeiten damit man einzelne Punkte herausbekommt. Dazu muss man aber einen Drehpunkt setzen.
Das der Roboter nur schräg läuft mit Drehung des Körpers halte ich für ein Gerücht: Auch hier gilt, er macht das was man ihm sagt.
Wenn er schräg läuft hat man ggf nicht die richtige Bahnberechnung ausgewählt.
Wenn es verschieden Zielpositionen die aber für den gesamten Roboter (Mittelpunkt, Centrum ...wie auch immer...) gibt, dann sind diese alle nacheinander zu berechenen und anzulaufen.
Wenn die Strecken unterschiedlich sein können, dann gibt es mehrere Wege nachdem man die Strecke A-Z des Körpers und der Beinkurve kennt:
1.die Bewegung der Beine anpassen, also kürzer oder länge Schrittweite.
2 die Bewegung mit vordefinierten fester Schrittweite und am Ende der Strecke den Rest des Weges ermitteln der nicht mehr in einen vollen Schritt passt. Das bedeutet das jedes Bein das letzte zu bewegbare Bein sein kann. Auch sollte man bedenken, das der Körpermittelpunkt nicht unbedingt auch den gleichen Abstand zu allen Fußpunkten haben muss - also nicht unbedingt der wirkliche Zielpunkt sein muss. Man könnte damit also auch noch etwas schieben und die Füße ggf extra nachberechnen wenn einen die Position eines einzelnen Fußes nicht gefällt. Da gilt es dann die erlaubte Toleranz einzustellen wo der Zielpunkt liegen darf, damit man mit den Beinen den Körper ggf letztendlich aufs Ziel schieben kann.
Ich verstehe Dein Bild mit dem unteren IF - Else nicht recht. Warum ist translatorisch zu rotatorsch getrennt? Wozu ist das gut?
Das Problem was ich hier sehe ist, das es nichts damit zu tun hat ob ein Betrag der Schritte je translatorisch zu rotatorisch größer als der andere ist?
Dazu müsstest Du nochmnal was sagen.
Der Winkel kann auch nicht einfach vorggeben werden, jedenfalls nicht wenn man auch gleichzeitig Koordinaten vorgibt - denn man weiß ja eigentlich garnicht ob der Winkel zu den Koordinaten passt, ob also die Gerade den Zielpunkt schneidet. Man kann nur eines von den beiden vorgeben, wo bei Vorgabe eines Winkel auch noch die Länge (Vektoren) der Strecke angegeben werden sollte, damit die Bewegung dort beendet bzw auch die Schrittzahl berechnet werden kann. Sonst läuft er eben weiter bis "was neues" kommt, dazu muss die maximale Schrittweite por Bein also zwingend vorhanden sein.
Also man erechnet sich Koordinaten aus Winkel + Länge oder den Winkel + Länge aus Koordinaten.
Ein Frage stellt sich mir noch: Welchen Schrittmodus benutzt Du als Grundlage 3x3, 4x2, 5x1? Mischung?
Meine Idee ist vielleicht kommt es zu einem Denkfehler wenn man sich auf eine bestimmte Schrittart einschiesst ala "ein Schritt muss immer genau so lang sein". Ich denke da liegt eher der Knackpunkt des Problems.
Um nochmal auf die sinnvolle Anzahl der Schritte zurück zu kommen: Die liegt zwischen einer Definition von maximaler Schrittlänge pro Schritt/Schub bis nicht bewegt.
Lege die maximale Schrittlänge fest, dann kannst du erst berechnen wieviele Schritte mindestens nötig sind.
Lege die minimale Schrittlänge fest, dann kannst Du berechnen wieviele Schritte maximal nötig sind.
Wichtig ist hier zu unterscheiden ob eine Kurve oder eine Strecke gelaufen werden soll.
Und auch ob die Koordinaten (kurze Strecken) mit Körperverschiebung nur mit Schub ohne Schritt zu erreichen sind und eine nachfolgende Korrektur der Fußpunkte gewünscht ist.
Das sind mal son paar von meine Gedanken dazu. Ich hab die Lösung auch noch nicht so richtig fertig - und solange kommt in meinem eigenen Beitrag auch nichts neues ;)
Es gibt grundsätzlich zwei Dinge zu unterscheiden:
1) Die Bewegung der Fußspitze über den Boden
2) Die Bewegung des Hexas durch den Raum.
2 folgt aus 1 bzw. 2 ist eine aneinanderreihung von Schritten (1).
Zu 1) Es gibt hier einmal eine translatorische Bewegung, dabei ändert sich die Ausrichtung des Hexas nicht. Soll heißen, er zeigt z.B. immer nach vorn und läuft dann eben Schräg (der Ego-Shooter-Spieler spricht von Strafen). Soll sich die "Blickrichtung" ändern, dann braucht es eine rotatorische Bewegung. Beide sind jedoch bei einem 3DOF Hexa unabhängig voneinander. D.h. er kann sich um jeden beliebigen Punkd drehen drehen oder eben schräg in alle Richtungen laufen.
Natürlich könnte man auch beide Bewegungen überlagern, dann kommt dabei raus, dass der Hexa z.B. 2m nach vorn läuft und sich dabei einmal um die eigene Achse dreht (Drehwinkel 360°, vereinfach um den Mittelpunkt des Hexas) d.h. zwischendurch würde er rückwärts laufen. Theoretisch möglich, aber schwer zu implementieren. Weiter müssen hier die ganzen Berechnungen zur Schrittlänge und ob sich die Fusspitze nun auf einem Bogen oder einer Geraden bewegt berechnet werden.
zu 2) Ausgehend von einem Start Punkt auf dem man ein Koordinatensystem legt (x und y, wie in meiner Zeichnung) und einem Zielpunkt der ebenfalls ein Koordinatensystem bekommt und einen Winkel. Warum? Nun bei der Berechnung von Industrierobotern hat man ein Basiskoordinatensystem (dort ist der Roboter befestigt) und ein Tool-Koordinatensystem (dort ist z.B. der Greifer). Es gibt eine Ist Position des Greifers und eine Soll Position des Greifes, die mit 6 Punkten angegeben wird, x,y,z und alpha, beta, gamma, da Greifer in allen Lagen orientiert werden können. Die Steuerung rechnet nun aus, wie aus der Ist, die Soll Position erreicht werden kann...DH-Matrix und so.
Zum Glück habe ich keinen Sechs-Achs-Roboter sondern einen deutlich einfacheren: Z-Achse gibt es nicht nur nur x und y (die translatorischen Bewegungen). Bei der Rotation sieht es noch einfacher aus, hier gibt es kein alpha und beta (solange der Hexa weiter parallel zum Boden ist) sondern nur um die Z-Achse = Gamma. Daraus ergibt sich eine Verschiebung in x und y Richtung plus eine Drehung. Vereinfacht man das oben gezeigte Beispiel indem man den Drehwinkel weg lässt, dann wird der Roboter einfach schräg durch den Raum laufen. Mit dem Drehwinkel 45° muss er sich auch noch drehen dabei. Allerdings wird er keine schöne Kurve laufen, wie man das bei einem Auto erwartet, sondern eben schräg zur Seite und dabei eine überlagerte Drehung ausführen. Diese Bahn zerlegt man dann in viele kleine Teilstücke und lässt sie den Roboter ablaufen.
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.
Richtig, maximale Schrittlänge wird durch die Mechanik bestimmt. Muss ich mal noch ausrechnen, welche Länge hier möglich ist bzw. welche Länge sinnvoll. Sollte die Strecke zwischen Ist und Ziel kleiner als 1 Schritt sein, dann kommt meine +1 in der Berechnung zum tragen (übrigens auch, wenn der Rest zum Ziel nicht ganz passt, dann wird eben nochmal ein Schritt mehr gemacht). Damit erreicht der Hexa zwar nicht exakt die Position, aber alle Beine bewegen sich und stehen danach wieder stabil.
Bisher habe ich mich nicht daran gewagt eine richtige Bahnkurve zu berechnen, warum:
Exkurs zum Thema Bahnkurven:
Nehmen wir als Beispiel ein Auto fährt um eine 90° Kurve. Zu Beginn steht das Auto mit der Ausrichtung Norden, am Ende steht das Auto mit der Ausrichtung Osten. Durch den Winkel der Vorderräder fährt es eine Kurve, solange der Radius dieser groß genug ist. Bei zu kleinen Radien, funktioniert es gar nicht, bei sehr großen Kurvenradien wird es ein sehr kleiner Lenkwinkel. Soweit dürfte das jedem klar sein. Bezeichnen wir diese Kurve als Bahnkurve und versuchen wir sie in der Mathematik abzubilden, wird es ein wenig komplex, denn wir müssen wissen wie groß der Radius ist und wo der exakte Mittelpunkt des Kreisbogens liegt. Für Teilstücke auf einem Kreis - wie bei einer 90° Kurve - ist die Bahnkurve sehr leicht mit einem Bogensegment (siehe Formel von Arkon) zu berechnen. Bei meinem letzten Hexa konnte ich die Koordinaten Kreismittelpunkts vorgeben und wieviel Grad das Kreissegment hat, eine reine rotatorische Bewegung.
Dieses Beispiel ist trivial, denn es hat nur einen Kreis den es zu berechnen gilt. Will man aber z.B. die Strecke von mir bis zu euch als Bahnkurve darstellen (vereinfacht nehmen wir eine Strasse), dann wird es eine Unmenge an Kreisen mit unterschiedlichen Radien und Mittelpunkten geben die aneinandergereiht werden, bzw. in manchen Fällen sogar eher etwas wie ein Polynom sein. Diese Bahnkurve mathematisch zu berechnen und dann in Teilstücken als einzelne Schritte abzulaufen dürfte noch mal um einiges mehr Aufwand bedeuten.
Zurück zum Auto und der 90° Kurve und wie mein Hexa diese Strecke bewältigen würde:
- Der Hexa würde einfach Schräg zum Zielpunkt laufen und sich dort um 90° drehen bzw. bei Überlagerung der beiden Bewegungen: eben schräg laufen und sich dabei drehen. Solange kein Hauseck im Weg ist kein Problem!
Praktisch: Egal wie klein der Radius des Kreises ist, der Hexa schafft es, da er auch auf der Stelle drehen kann.
Praktisch 2: Er wählt den kürzesten Weg um das Ziel zu erreichen.
Unpraktisch: Er bleibt am Hauseck hängen.
- - - Aktualisiert - - -
Und weils so schön ist, hier meine persönliche Aufgabenstellung.
Folgende Bahn soll im Hexabot implementiert werden:
Anhang 26432
Erlärung: Der Roboter startet bei Pos 1 mit Ausrichtung nach rechts. Läuft einer Kreisbahn bis zu Pos 4. Verändert dann die Ausrichtung zum Mittelpunkt Pos 5. Diese Bewegung von 4 zu 5 ist eine überlagerte translatorische und rotatorische Bewegung. Danach bewegt sich der Roboter auf dem Kreisbogen mit Ausrichtung auf die Mitte. Ab Pos 8 schräg Richtung Pos 10. Alternativ kann auch hier wieder eine überlagerte Bewegung implementiert werden, dann is die Ausrichtung des Roboters am Ende (Pos 10) parallel zur Geraden.
Bisher kann mein Phoenix² nur entweder translatorisch oder rotatorisch:
http://www.youtube.com/watch?v=SEEkO_U-VHM
Siehe 1:02 bis zur Flasche laufen, dann um die Flasche drehen mit Ausrichtung auf die Flasche.
Ab 1:47 translatorische Bewegungen gerade aus, schräg, rückwärts.
Vereinfacht könnten man von Pos 8 zu Pos 10 auch mit 1 Schritt trans, 1 Schritt rota, erreichen.
Also Hanno,
ich denke wenn man eine Gerade oder einen Bahnkurve läuft, dann zählt alleine der nächste Punkt der von den Beinen angefahren werden soll.
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.
Die Ausrichtung wohin der Roboter läuft hängt davon ab, ob sich das Koordinatensystem gedreht hat oder nicht. Das dreht sich also nur, um im Beispiel von mir zu bleiben, wenn man ihm einen Winkel vorgibt der der nächsten Steigung des nächsten Geradensegments entspricht. Jetzt dreht man das Koordinatensystem des Roboters dem nächsten Winkel entsprechend. Wenn man die Winkel Änderung danach wegschmeisst hat man keinen Bezug mehr zum Urschprung, deswegen muss der mindestens mit der bisherigen Winkeländerung aufgerechnet werden. Das würde die Bahnkurve der Körpermittelpunktes ergeben.
Daneben muss aber für jedes Bein auch eine Berechnung durchgeführt werden die die Beine zur Körperbewegung mitnimmt- also in die IK gegegben wird - da wäre dann auch der Abstand des Beines von Körpermittelpunkt wichtig. Jetzt stellt man entweder jedem Bein eine eigene Kurve für die Fußpunkte bereit, oder lässt je eine Beinseite auf nur einer Kurve laufen. Die beiden Kurven teilt man auch in die Anzahl der Segmente der Körperkurve.... wobei ich grade beim schreiben merke, die braucht man dann wohl auch nicht mehr... - also es ergeben sich mindestens zwei Kurven eine mit kurzen, eine mit langen Segmenten, die Segmentschnittpunkte werden mit Geraden verbunden und diese langen Geraden dürfen nun nicht länger sein als die maximale Schrittlänge eines Beines.
Wenn man jetzt den Winkel zum Zielpunkt berechnet hat, kann kann man darüber auch die Geradenteilstücke berechen entweder mit Drehung oder ohne, wichtig ist nur das die Beinberechnung davon weiß ob ein Drehwinkel vorliegt oder nicht - also ob schräg gegangen werden soll oder pro Geradensegment um den anteiligen Winkel mitgedreht wird.
Fazit: Zum Laufen würde ich zwei Geradensegmente aus n-Segmenten einführen, auf denen sich die Fußpunkte befinden, eine Radius wird bestimmt je nachdem wie stark die Kurve sein soll <= 90°; der Abstand des Fußpunktes zum Körpermittelpunkt wird bestimmt um den Abstand der Fußkurve vom Körpermittelpunkt und damit die Länge der Geraden auf der inneren sowie Äusseren "Kurve" zu erhalte.
Zeichen mal eine Kreis auf Deinen Koordiantensystem oben, mit einem Schnittpunkt im Startpunkt und einem im Zielpunkt - dann zeteilst Du das kürzer Kreissegment gleichmässig mit Geraden. Der Winkel alpha wird automatisch pro Gerade anteilig mit geteilt.
Schon richtig, aber irgendjemand muss ihm ja sagen, wohin der nächste kleine Schritt gehen muss. Also kommt wieder die Bahnkurve ins Spiel.Zitat:
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.
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.
Darauf läuft es hinaus und die Mathematik dafür gilt es zu entwickeln.Zitat:
Jetzt stellt man entweder jedem Bein eine eigene Kurve für die Fußpunkte bereit...
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.Zitat:
...oder lässt je eine Beinseite auf nur einer Kurve laufen
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!
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.
@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!
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.
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.
Leider geht es genau darum!Zitat:
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.
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!
Anhang 26438Anhang 26439
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.
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.
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.
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 = 8). Bei einer Drehung entsteht ein Winkel zwischen dem ursprünglichen und dem Zielkoordinatensystem: Daraus folgt, dass die Bewegung V1 (1 5) und V2(1 8) 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.
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
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.
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:
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:Zitat:
Zitat von HannoHupmann
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.
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
Das dürfte die einfachste und flexibelste Umsetzung sein.Zitat:
Zitat von HannoHupmann
Ä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.