Zitat Zitat von HannoHupmann
Mit der Inversen Kinematik ist das so eine Sache. Den sie ist z.Z. in aller Munde und jeder meint oder hofft damit seine Bewegungsmuster am Hexabot berechnen zu können. Leider ist es nicht ganz so einfach.

Einfach ist es mittels Trigonometrie zu ermitteln welche Position die Fussspitze in der Ebene hat und die daraus resultierenden Winkel für die Servos. Allerdings gibt es für jeden Punkt verschiedene möglichkeiten bzw. Glenkstellungen. (Lässt sich sehr schön selbst testen mit einer Kaffeetasse. Um diese zu greifen von einer festen Position aus, gibt es mehre Möglichkeiten für den Arm, die Beste nutzen wir rein intuitiv, wer aber mal ein bischen experimentiert wird schnell Hand/Ellenbogen/Schultergelenk Stellungen finden die entweder unpraktisch oder auch eine Lösung sind)

Schwiriger wird es wenn man sich wirklich alle kinematischen Effekte zunutze machen will und nicht nur über die Position sondern auch über die Kräfte eine Aussage machen möchte.

Abgesehen ist Kinetik (ob invers oder normal) immer eine Rechnung mit Bewegung, d.h. erste genannte Trigonometrische Berechnung ist eigentlich inverse Statik und keine Kinematik. Nichts desto trotz kommt man mit inverser Statik schon recht weit und für uns Hobbybastler sollte es eigentlich auch reichen.

Ein weiteres Problem wird leider immer wieder unterschätz. Hat man einmal einen Algorithmus der einen Punkt im Raum mit der Fussspitze exakt anfährt und alle Gelenke entsprechend steuert, dann braucht man aber immernoch die Punkte im Raum.

D.h. ein weiterer Berechnungsalgo ist notwendig um Punkte im Raum zu generieren die von den Fussspitzen angefahren und dabei die Schrittfolgen eingehalten.

Bis auf den Roboter von MeckPommER hab ich beim ganzen Hype um Hexabots noch keinen weiteren gesehen (hier im Forum) der mittels "hobby inverser Kinematik" seine Schritte steuert.
Danke für die gute Beschreibung
Ich denke, dass ich alles durcheinander würfeln werde, hab zu wenig plan davon, als dass ich was in eine ganz spezielle Richtung machen könnte

Das alles wird sicher noch n harter Brocken und ich mach mir sehr viel Gedanken darüber

Z.B. auch über die Wiederfindung bestimmter Positionen.

Schon etwas älter, hab meine Gedanken entsprechend meinem Verständnis und meinen derzeitigen Wissenstand freien Lauf gelassen:

#############################################

Überlegungen - Bewegungsmuster schreiben und lesen
------------------------------------------------------------------------------------------

# Algorythmus "Vorwaerts" Version 1 (vertikal)
(jede Zeile für 1s durchlaufen)

Zeichen:
1 = MVL1.3
2 = MVL1.2
3 = MVL1.1
4 = MHL1

5 = MVL2.3
6 = MVL2.2
7 = MVL2.1
8 = MHL2

9 = MVL3.3
10 = MVL3.2
11 = MVL3.1
12 = MHL3

13 = MHR3
14 = MVR3.1
15 = MVR3.2
16 = MVR3.3

17 = MHR2
18 = MVR2.1
19 = MVR2.2
20 = MVR2.3

21 = MHR1
22 = MVR1.1
23 = MVR1.2
24 = MVR1.3

SSSSSSSSSSSSSSSSSSSSSSSS
SUSSSSSSSSSSSSSSSSSSSSSS
SUSSSSSSSSSSSSSSSSSSSSSS
UUSSSSSSSSSSSSSSSSSSSSSS
UUSSSSSSSSSSSSSSSSSSSSSS
USSSSSSSSSSSSSSSSSSSSSSS
USSSSSSSSSSSSSSSSSSSSSSS
USSSSSSSSSSSSSSSSSSSSSSS
SDSSSSSSSSSSSSSSSSSSSSSS
SDSSSSSSSSSSSSSSSSSSSSSS
DDSSSSSSSSSSSSSSSSSSSSSS
DDSSSSSSSSSSSSSSSSSSSSSS
DSSSSSSSSSSSSSSSSSSSSSSS
DSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSS

^Front^
------------------
MVL1.3 --- MVL1.2 --- MVL1.1 --- MHL1 --- O} {O --- MHR1 --- MVR1.1 --- MVR1.2 --- MVR1.3
] [
MVL2.3 --- MVL2.2 --- MVL2.1 --- MHL2 --- O} {O --- MHR2 --- MVR2.1 --- MVR2.2 --- MVR2.3
] [
MVL3.3 --- MVL3.2 --- MVL3.1 --- MHL3 --- O} {O --- MHR3 --- MVR3.1 --- MVR3.2 --- MVR3.3
------------------
| |
| |
| |
| |
Y




Vermerk:
Es werden Standard-Algorythmen festgelegt (vorwärts, rückwärts, seitwärts, abwähr, ...), welche in Textdateien auf einem Datenträger (SD-Card) geschrieben sind, von dort werden entsprechende Algorythmen gefordert.
Motorgeschwindigkeit (via PWM) wird ebenfalls festgelegt.

Bei Kollision/ Hindernis wird der Lesevorgang unterbrochen, wenn es keinen alternativen Algorythmus gibt, durchläuft das Hauptprogramm eine Zufallroutine, die Bewegungen werden von jetzt an in eine neue Textdatei mit Vermerk der entsprechenden Kollision (welcher Sensor wurde ausgelöst) und welcher Algorythmus durchlaufen wurde, geschrieben.

Wenn Hindernisumgehung erfolgreich war, dann läuft entsprechender Standard-Algorythmus weiter.

Wenn Hinternisumgehung fehlgeschlagen ist, dann wird Zufallsroutine erneut durchlaufen und die neue Datei überschrieben, bis der Erfolg eintritt.

Die durch Kollisionen oder Ereignisse gespeicherten Daten werden bei späteren Kollisionen oder Ereignissen angefordert, dabei werden "ausgelöster Sensor" und "passender Algorythmus" berücksichtigt.

Ist keine Übereinstimmung der Hindernisumgehung zu finden, wird eine neue Datei angelegt... u.s.w.


Stand: 2007-07-18


#############################################


Ich hab keine Ahnung, ob das funzen kann, aber jede Menge Hoffnung, weil bisher irgendwie doch, wenn auch mit Abstrichten, alles funzt hat, was ich mir vorgenommen hatte \/
Das wird auch noch einige Male überarbeitet

Was meinst dazu?

Andreas