@Ikarus_177 den Ansatz haten wir ein paar Beiträge weiter vorn auch schon diskutiert und an dem werde ich auch festhalten. Bahnkurve bedeutet in der Tat vorberechnet, da es ja eine Zentrale Vorgabe geben muss wohin der Roboter laufen soll. Das würde ich als die "Bahnkurve" definieren (sprich einen Meter gerade aus und dabei eine 360° Drehung). Allerdings ändert sich die Lage des Roboters wärend der Bewegung immer wieder so, dass diese "Vorberechnung" nur teilweise gültig ist und der Weg der zurück gelegt wird in entsprechende viele Teilstücke zerlegt ist. So wie du das mit dem dx, dy gemacht hast nur dass es bei mir noch ein dh (Höhe) geben wird für jeden "Schritt"
Dein Einwand mit beide Beine hinten oder beide Beine vorne ist richtig und muss entsprechend im Programm verhindert werden, ich weis nur noch nicht ob das Zentral oder Lokal passiert.

@robin
Genau so denke ich dass es in der theorie funktionieren könnte. Das ist im Endeffekt ziemlich ähnlich zu dem was Ikarus_177 beschrieben hat. Die Bewegung im Raum wird zerlegt in Teilschritte und dann in Servobewegungen umgerechnet.

Langsam ergibt sich auch für mich ein Bild wie es aussehen könnte und schwierig wird es nun nur das ganze theoretische Gebilde in einen funktionierenden Code umzusetzen (insbesondere der Mathematik) und dann auf meine µC Struktur zu verteilen.

Ich verwende wieder (wie bei meinem Phoenix²) einen Propeller Chip von Parallax der hat 8 µC integriert die alle unabhängig voneinander arbeiten können und sich einen gemeinsamen Memory Pool teilen.
Im Moment denke ich, dass jeder Cog (so nennen die die einzelnen µC) ein Bein bekommt und damit zwei Cogs übrig bleiben für die zentrale Berechnung der Bewegung.
Da die Cogs auf einen gemeinsamen Memory Pool zugreifen können sie hier ohne Probleme ihr dx, dy und dh Werte abholen und selbstständig in die Servowinkel s0, s1 und s2 Umrechnen und ausführen. Nach jedem dx, dy, dh Schritt warten sie auf neue Werte oder halten die Position. Außerdem könnte jeder Cog selbst prüfen ob die Übergabewerte in Ordnung sind oder zu illegalen Servowinkeln führen (Berechnungsfehler) würden. Auch die Regelung, dass sich die Beine vorn oder hinten nicht gleichzeitig vom Boden abheben, sollte hier erfolgen.

Der Charm dieses µC sind wirklich die 8 unabhängig und echt parall arbeitenden Kerne. Bei meinem Phoenix² arbeite ich teilweise parallel, dort berechnet Cog1 die Bewegungen und Cog6 bewegt alle rechten Beine und Cog7 alle Linken. Abgesehen davon unterstützt die Programmiersprache inline Assembler Code, so dass man alles was "schnell gehen soll" in Assembler programmieren kann und alles übrige in SPIN. Achja eine sehr umfangreiche Tabelle mit Cosinus Werten ist auch schon fest implementiert, das heißt er berechnet den Wert nicht sondern schaut einfach nach, was gerade für diese Anwendung im Hexa sehr praktisch ist.


PS: Neue Servos für die Schultern hab ich trotzdem noch gekauft, um nicht in Probleme mit dem Drehmoment zu laufen, denn 73Ncm bei einer Belastung von 72Ncm im 45° Winkel fand ich dann doch zu kritisch. Daher gibt es jetzt einen Satz 142Ncm Servos (Zudem noch Digitale und keine Analogen) für die Schultern, womit selbst bei 90° ausrechend Leistung zur Verfügung steht und der Roboter auf ein Maximalgewicht von 3,9kg kommen dürfte (vier Beine immer am Boden).