ZitierenMal schaun, wie gut ich bis dort hinkomme
Mal schaun, wie gut ich bis dort hinkomme
Bei dir geht ja wie immer ganz schön was.
Immer wieder spannend zu lesen wie dein Projekt voranschreitet.
Du und Hanno habt zwei ganz heisse Eisen am laufen =D>
Weiteres Problem bei der "inversen Kinematik für Bastler" (*g*) ist nicht nur die Berechnung der Aufsetzpunkte der Beine im Raum und die Berechnung der dazugehörigen Servostellungen, sondern auch das Generieren der Bewegungsmuster zum Setzen der Beine (Hub- und Stemmphase). Bislang sah das bei meinem Pod auch immer aus wie bei Pinoccio auf Extasy - von elegantem Schreiten war da keine Spur zu sehen.
Das habe ich die letzten Tage ganz gut hinbekommen (Video kommt wohl so ca. am Wochenende).
Ich denke, letzten Endes ist die statische Variante schwieriger. Das IK-Problem wird ein Mal gelöst und dann ists erledigt. Ich kann Marvin schräg nach vorne rechts gehen lassen und sich dabei um seine eigene Hochachse nach links drehen lassen und dabei nach rechts kippen lassen. Jede noch so verquere Bewegung besteht nur darin, das ich im Richtungen und Winkel vorgebe - den Rest macht er selber.
Ein weiterer enormer Vorteil ist die Standorterkennung. Da bei der IK die Beine sicheren Kontakt zum Boden haben und bei den Bewegungen nichts "schlüpft", weiß das Programm stets, wo der Pod ist, und in welchem Winkel er sich befindet. Das ist mit der statischen Lösung nur sehr ungenau abzuschätzen.
Ein großes Problem bei copious statischer Variante sehe ich momentan bei dem Punkt "Wenn Hindernisumgehung erfolgreich war".
Wie soll der Bot das erkennen, und was zählt als Hindernisumgehung? Falls als Erfolg gilt, das der betreffende Sensor keinen Alarm mehr macht, so würde sich ein Szenario ergeben, bei dem der Bot vorwärts gegen eine Wand läuft, die Sensoren Alarm schlagen, der Bot z.b. Rückwärts zuckt, Sensor meldet "alles klar", und dann läuft der Bot wieder gegen die Wand.
Aber es ist wirklich so: in jedem kleinen Problem steckt ein Großes, das raus will
Mein Hexapod im Detail auf www.vreal.de
@MeckPommER Das mit den Punkten im Raum generieren ist eben ein weiteres Problem bei der ganzen Berechnung.
Übrigens bitte aufpassen mit den Begrifflichkeiten, es gibt dynamisches und statisches Laufen und statische und dynamische inverse Kinematik, beides lässt sich beliebig miteinander kombinieren.
Die Inverse Kinematik die wir verwenden ist die mittels Sinus und Cosinussatz und keine algebraische. Wenn man Die Probleme algebraisch löst kommen sehr viel schwerere Rechnungen raus. (die lassen sich aber wenn man weis wie genauso schnell und einfach lösen, bzw. sind für Computer sogar einfacher (soweit ich es bisher schon überblicken kann)).
Ganz sicher kann man sich trozt der IK nicht sein, dass ein Bein da ankommt wo es soll; außer man hat so gute Servos, die einem ihre Position rückmelden.
Dein letzter Punkt mit dem Problem ist natürlich richtig, der hat aber nichts mit dem laufen oder der IK zu tun sondern mit der Intelligenz des Roboter allgemein. Sich einen guten Algorithmus für ein definiertes Verhaltensmuster zu überlegen ist zwar gänzlich anders aber nicht zwingend minder kompliziert.
Aber ich würde mir darüber erst Gedanken machen, wenn ich meinen Roboter soweit habe, dass er vorwärts, rücktwärts usw. laufen kann.
Hi
Da sprechen die Profis in Sachen IK
@MeckPommER
So wie du es beschrieben hast, habe ich das auf einigen Videos sehen können, absolut elegant, wie sich manche Roboter bewegen können, auf sowas möchte ich mal hinaus \/
Diese Überlegung ist auch schon etwas älter, grüble da fast jeden Tag drüber und schliesse das eine aus, hab dann aber wieder ne neue Idee u.s.w.Zitat von MeckPommER
Erster Gedanke wegen "Wenn Hindernisumgehung erfolgreich war", es wird z.B. eine Laufbewegung z.B. "Vorwärts" ausgeführt, bei einem Hindernis bleibt der Roboter stehen, bzw. bewegt sich n Tick zurück (wie auch der Mensch oder Tiere sich reflexartig bei Hindernissen oder Kollisionen verhalten) und führt dann wieder diese Laufbewegung "Vorwärt" aus, nur diesmal auf eine veränderte Art (Bein höher ansetzen oder mehr anwinkeln...) was dann aber abhängig von den ausgelösten Sensoren ist. Wenn z.B. der vordere Sensor an Bein 1/ links Modul 3 (äusseres Modul) kontakt hat, würde sich das Modul anwinkeln. Wenn das auf beiden seiten, also links und rechts passiert, dann weiss der roboter, er steht entweder vor ner wand oder kollidiert links und rechts z.b. jeweils an n stuhlbein oder so, dann würde er links und rechts die module anwinkeln (strecken geht nicht, weil das ausserhalb seiner bewegungsfreiheit gehen würde) und es erneut versucht, kollidiert er wieder und die beine können nicht weiter angewinkelt werden, dann weisser, er muss es drüber, drunter durch oder dran vorbei versuchen und so weiter \
Aber es ist wirklich so: in jedem kleinen Problem steckt ein Großes, das raus will
Ohne vorher zu recherchieren oder irgendwo nachzulesen habe ich mir gerade mal n paar Gedanken zur Winkelbestimmung gemacht und versucht es festzuhalten.
Die Steuerung einen Beines wird 3 Funktionen haben (da steht schon fest):
- heben/ senken
- vor/ zurück
- strecken/ anwinkeln
... und zum letzteren ist zu sagen, dass hier zwei Motoren synchron laufen müssen bzw. den identischen Winkel beim strecken/ anwinkeln beibehalten müssen \
Und hier meine Überlegung:
Ich gebe einen Wert vor, der dann auf beide Gelenke geteilt wird
PS: Hier kann maximal ein Winkel von 1 Grad beim "anwinkeln" erreicht werden, alles im ganzen ist nur n Gedankenblitz, keine Ahnung ob mich das zu nem vernünftigen Ergebnis bringt, zumindest geht die Rechnung auf
Was meint ihr dazu?
Den Vorteil bei dieser Überlegung sehe ich darin, dass ich nur einen Hauptwert (r) zum Steuern habe, als wenn ich nur einem Motor sage, wie weit er sich bewegen soll
Schaut irgendwie falsch aus also die Rechnung bezüglich Zeichnung, den was du gezeichnet hast sind etwa r = 90°
Gehen wir mal von 90° aus, dann haben die ra und rb gegenüber liegenden Winkel 45° und ra tatsächlich 135° etc etc.
so kannst du es natürlich machen, aber günstiger ist eine Vorgabe nach dem Prinzip Länge x = Abstand von Fussspitze zu Hüftgelenk und Länge h = Höhe des gesamten Systems über dem Boden.
Den wenn die Winkel nach x und y aufgelöst werden, kann mittels der Hüftdrehung in z Richtung jeder beliege punkt mit beliebiger Höhe erreicht werden, so er sich im Aktionsradius befindet.
Über Winkelfunktionen lassen sich natürlich invers die Winkel berechnen.
Die Höhe brauchst du übrigens auf jedenfall, da du das Bein sonst nie hochheben kannst bzw. dafür keine Position festlegen.
Hi Hanno
Heben und senken kann sich das Bein trotzdem, die Zeichnung ist nur ne Skizze
Der Winkel vom Gelenk "heben/senken" wird auf den Hauptwinkel für "strecken/ anwinkeln" abgestimmt, so dass sich der Hauptwinkel anpasst, wenn sich der Körper höher oder niedriger über dem Boden befindet. Aber das sind nur Gedanken
Schon klar, dass du mit dem einen Motor in der Hüfte heben und senken machen kannst, nur ist es nicht besonders günstig diesen die ganze Arbeit machen zu lassen, abgesehen davon sieht es nicht besonders elegant aus.
Wenn du nämlich nur dort heben und senken machst, brauchst du in ra und rb keine Motoren einbauen sondern kannst es starr machen.
Außerdem ist es wichtig, die Fusspitze weiter hinaus oder hinein stellen zu können um den Kreisbogen des Hüftservos ausgleichen zu können. Die Position der Servos MUSS also vom Abstand zwischen Fussspitze und Hüftservo abhängen, daraus resultiert dann ra und rb sowie rc für die Schultern heben/senken.
Die Berechnung dafür ist nicht besonders Kompliziert, man brauch Cosinus und Sinussatz und Pythagoras mehr aber nicht und es hilft einfach mehr fürs Verständnis es sich selbst zu überlegen. Abgesehen davon kursieren bereits ein paar Lösungen
Berechtigungen
Lesezeichen