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