Das mit dem mathematischen Modell ist so eine Sache und hat einige Tücken.

Als erstes müssen wir unser Koordinatensystem festlegen und Vereinbarungen treffen.
Der Hexabot bewegt sich in einem 3D Koordinatensystem.+-X ist rechts/links, +-Y ist oben/unten, +-Z ist hinten/vorne. Der ebene Boden hat den Y-Wert Null. Der Hexapod hat einen zu definierenden Mittelpunkt, der seine Position angibt und um den er sich dreht, kippt und neigt. Die seche Beine haben eine relative Position dX,dY und dZ zu diesem Mittelpunkt. Beim Programmstart wird der Mittelpunkt festgelegt, z.b. mit XYZ = (0,6,0), denn der Hexapod muss ja schon eine gewisse Höhe haben und kann nicht in der Tischplatte versinken. Ebenso werden beim Programmstart die Bodenpunkte der einzelnen Beine berechnet. Ich habe es so gemacht, das diese etwa 8 cm seitlich, des jeweiligen Hüftservos liegen, auf selbigem Z-wert und logischer Weise am Boden sind, also Y=0.

Die einige Aufgabe der Beine ist nun, den Achspunkte der Hüftservos mit den Bodenpunkten zu verbinden.

Ich habe festgestellt, das man sich der Sache am besten Stück für Stück, also Servo für Servo nähert. Nehmen wir mal den Hüftservo:
Zu wissen, welche 2 Raumwinkel vom Hüftservo in Richtung Bodenpunkt zeigen ist schon 50% zuviel gerechnet. Der Hüftservo stellt sowieso das Bein nur nach hinten oder vorne. Also recht es, den Winkel auszurechnen, der sich ergibt, wenn man von oben auf den Hexabot schaut (dumm ausgedrückt, aber ich hoffe, verständlich).
Das gemeine ist nun, das wir jetzt einen anderen Punkt im Raum für die weiteren Berechnungen nehmen müssen, nämlich nicht mehr den Drehpunkt des Hüftservos, sondern den Drehpunkt des nächsten Servos: des Knieservos.
Der errechnet sich aus der Position des Hüftservos, der Strecke zwischen Hüftservo und Knieservo (also der Länge des Oberschenkels) und des gefundenen Winkels.
Sich jetzt den Winkel des Knieservos auszurechnen ist nur was für starke Männer und leistungsfähigere Controller, weil wir den Servo so stellen müssen, das das Ende des Unterschenkels genau so weit vom Bodenpunkt ist, wie das Fusssegment lang ist. Erstens ist das ne fiese Rechnerei und zweitens bekommt man unter Umständen zwei Ergebnisse :-/
Also gehen wir nen anderen Weg, der viel einfacher und schneller ist. Wie wissen, wie lang der Unterschenkel ist, wir wissen, wie lang das Fusssegment ist, und wir wissen, wie weit es vom Drehpunkt des Knieservos bis zum Bodenpunkt ist. Diese drei Strecken bilden ein Dreieck, und da wir alle drei Längen kennen, können wir auch den Winkel berechnen, den der Fussservo haben muss (Cosinussatz). Der Fussservo ist es nämlich, der dann sozusagen das Dreieck aus Fusssegment und Unterschenkel so weit aufspannt, das der Fuss genau am Bodenpunkt ankommt.
Als letztes muss der Winkel für den Knieservo berechnet werden. Der ergibt sich aus dem Winkel vom Knieservo zum Boden und dem Winkel des Fussservos. Voila

Das Gehen erfolgt dann durch einen Impuls der auslöst, das für einen kurzen Moment der Controller statt der realen Bodenposition eine Position + 4cm Y bekommt, dann hebt er artig das Bein. Währenddessen wird dann eine neue Bodenposition berechnet.

Was wir an Programmtechnisch an Funkionen brauchen sind Sinus- und Cosinussatz, sowie Funktionen, die uns Punkte im Raum drehen und verschieben können. Denn wenn der Hexapod sich bewegt, bewegt sich sozusagen mathematisch die Welt unter ihm weg. Wenn ich will, das er sich dreht, kann ich nicht einfach seine Koordinaten drehen, sondern muss seinen Mittelpunkt erst auf den Mittelpunkt des allgemeinen Koordinatensystems schieben, dann kann ich drehen, und dann schiebe ich wieder zurück.
Das Hin- und Herschieben ist eine unproblematische Sache. Aufpassen muss man beim Hin- und Herdrehen! Wenn ich z.B. irgendeinen Punkt im Raum nehme, und drehe ihn um den Ursprung in allen drei Achsen erst um a Grad um die X-Achse, dann um b Grad um die Y Achse und dann um c Grad um die Z Achse und drehe ihn danach wieder zurück um -a Grad X, -b Grad Y und -c Grad Z, dann mach ich dicke Backen, weil der Punkt irgendwo ist, aber nicht am Punkt von vorher. Grund dafür ist, das es beim Drehen auf die Reihenfolge ankommt. Ich muss also aufpassen, das ich beim zurückdrehen auch die Reihenfolge umkehre. Es muss also zuerst -c Grad Z, dann -b Grad Y und dann -a Grad X gedreht werden.

Was braucht man für nen Controller?

Ich habe einen Atmega32 Controller für je zwei Beine. Das ist etwas überdinemsioniert, aber ich möchte mir Power und Platz in Reserve halten um noch weiter feilen zu können. Wenn man die Erzeugung der Servoimpulse auslagert, alles feinstens optimiert und z.B. die Trigonmetrischen Funktionen als Tabelle speichert anstatt sie zu errechnen, dann mag man mit einem Controller auch alle 6 Beine berechnet bekommen. Allerdings wird das so eng, das ich es nicht versucht habe. Ich möchte noch Platz dafür haben, das der Hexapod Taster an die Beine bekommt, und reagieren kann, wenn ein Bein beim Aufsetzen mal ins Leere tappt oder zu früh Kontakt mit irgendwas hat.
Ein Atmega 8 ist aber definitiv zu klein dafür, sowohl an Rechenpower als auch an RAM und Programmspeicher. Um ein flüssiges Gehen zu ermöglichen, sollte die komplette Beinberechnung schon mindestens 50 Mal pro Sekunde erfolgen, damit der Hexabot nicht tackert in den Bewegungen.
Auch sollte man den Servo nicht mit den z.B. in Bascom existierenden Servobefehlen ansprechen, da der Servowert dort ein 8-Bit Wert ist. Selber eine Interrupt-Routine mit einem 16-Bit Timer ist viel eleganter und genauer.