- 3D-Druck Einstieg und Tipps         
Ergebnis 1 bis 4 von 4

Thema: Quadruped/Hexpod - fortgeschrittene Kinematik - Ansatz gesucht

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Erfahrener Benutzer Roboter-Spezialist Avatar von erik_wolfram
    Registriert seit
    02.12.2009
    Ort
    Berlin
    Beiträge
    406

    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
    Geändert von erik_wolfram (15.03.2013 um 09:39 Uhr)
    Meine Projekte auf Youtube

  2. #2
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    26.11.2004
    Beiträge
    451
    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

  3. #3
    Erfahrener Benutzer Roboter-Spezialist Avatar von erik_wolfram
    Registriert seit
    02.12.2009
    Ort
    Berlin
    Beiträge
    406
    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...
    Meine Projekte auf Youtube

  4. #4
    Erfahrener Benutzer Roboter-Spezialist Avatar von erik_wolfram
    Registriert seit
    02.12.2009
    Ort
    Berlin
    Beiträge
    406
    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...
    Meine Projekte auf Youtube

Ähnliche Themen

  1. Verzögerte PWM ausgabe. Ansatz gesucht.
    Von BlaueLed im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 7
    Letzter Beitrag: 27.07.2010, 11:02
  2. Mein Laufroboter: Fully Documented Hexpod Robot Project
    Von mcs im Forum Vorstellungen+Bilder von fertigen Projekten/Bots
    Antworten: 17
    Letzter Beitrag: 06.04.2009, 08:17
  3. 5 Sensoren - 2 Motoren - Nibo - KI-Ansatz in C gesucht
    Von ehenkes im Forum Software, Algorithmen und KI
    Antworten: 0
    Letzter Beitrag: 29.07.2007, 22:41
  4. Hexpod beine bewegen
    Von spomue im Forum Allgemeines zum Thema Roboter / Modellbau
    Antworten: 7
    Letzter Beitrag: 06.07.2006, 11:25
  5. ASURO: probleme mit der programmierung für fortgeschrittene.
    Von Atreyu im Forum C - Programmierung (GCC u.a.)
    Antworten: 13
    Letzter Beitrag: 20.11.2005, 10:51

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Solar Speicher und Akkus Tests