Projekt Marvin - Mein Hexabot zu 30-40 % fertig

[HannoHupmann]

@MeckPommER haben wir schon mal versucht mit dem für alle Breittreten, das hat auch zu mehr oder minder guten Ergebnissen geführt, ich hab auch selber gerade nochmal ein paar Gleichungen aufgestellt.

Das Problem ist leider wenn man es im Thread macht, dass meistens soviele mitreden mit so unterschiedlichen Wissenstand, dass man schnell gar nichts mehr versteht und es zu unübersichtlich wird.

Abgesehen davon, ist das Forum nur sehr schlecht geeignet um Mathematik zu Diskutieren, da bräuchte man schon nen Tafel um es vernünftig machen zu können.

Ich versuch gerade Gleichungen zu finden nach denen der Winkel der Servos in Abhängigkeit von z und x koordninate (von der Fussspitze) ist mit dem Hüftgelenkt wären damit alle 3 Kordninaten im Raum bestimmt. Nur ein wenig Probleme hab ich noch wie man den Körper in seinen 6 Freiheitsgraden mathematisch beschreibt.

[EDIT] Alles wieder weg ich denk erst mal nach bevor ich was sag.

[EDIT2] Hab jetzt ein mathematische Modell wo die Winkel der Servos von den x,y,z Koordinaten im Raum abhängen

[MeckPommER]

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.

[HannoHupmann]

Ok zu deinem letzten Satz noch ein paar Worte (mathematisch hab ichs begriffen und muss es nur noch entsprechend umsetzen). Theoretisch könnte man ja den ganzen Rechenschmarn von einem Leistungsfähigen Controller übernehmen lassen (ka was genau geeignet ist) und dann die Errechneten Werte über I²C an das Servoboard übermitteln. Dieses muss dann nur noch ausführen und die Werte an die richtigen Servos übergeben.

Die Trigonmetrie würde ich tatsächlich in eine Tabelle speichern bzw. nur dann live berechnen, wenn wirklich genügend Rechenkapazität frei ist. Erweitern kann man das ganze System immernoch indem man zusätzlich µC die Vorauswahl bei der Sensorverarbeitung treffen lässt.

Fragt sich nur welcher µC wirklich Leistungsfähig genug ist um 6x komplett alle Beine und dann noch in 50Hz zu berechnen.

[MeckPommER]

Gute Frage, die ich dir nicht beantworten kann. Ich würde es einfach mal mit nem Atmega 16 versuchen. Sollte der nicht ausreichen vom Platz her, kannst du immernoch auf einen Pinkompatiblen 32 oder 64 ausweichen.
Bei einer Tabelle ist auch immernoch die Frage, wie genau man die anlegt mit wievielen Werten *kopfkratz*. Auch soll das Heraussuchen der Daten ja nicht länger dauern als die live-berechnung.
Wenn ich nicht irre, hab ich mal nen Sinus Benchmark gemacht, bei dem herauskam, das der atmega32 bei 16MHz so ca. 8000 Sin pro Sekunde schafft. Gibt ja tausend Ecken, an denen man speedmäßig feilen kann.

Das alles ist auch der Grund, warum ich mein ganzes System modular aufgebaut habe. Ich kann ohne Probleme einfach z.B. einen neuen Beincontroller für 6 Beine entwerfen, nehme die 3 alten Controllerboards runter und stecke das Neue auf - ich haben fertig. Da innerhalb der Entwicklung ja auch immer neue Ideen kommen, kann ich mich so ganz flexibel dem Endziel nähern ... was ohne Zweifel auch wesentlich hübscher sein soll, als es jetzt aussieht

[HannoHupmann]

Ich weis schon wen ich da mal anhauen werde bezüglich Controller, da gibt es ein paar Informatiker bei mir an der FH (und ein paar Profs) die mich davon überzeugen wollen, dass ihre Atmega ganz toll sind. Daher muss ich die mal fragen oder meine Systemprofessorin die hat auch immer gute Ideen.

Nun so gesehen dürfte jedes Bein damit 20 Trigonometrische Funktionen haben um die geforderten 50Hz einzuhalten und man davon ausgeht dass alle Trogonometrischen Funktionen gleich lange brauchen.

Bei mir wird es auch Modular allerdings nicht ganz so viele Module sondern eben nur 2-3 Controller Module.
1 Main, 1 Servos, 1 Sensor und damit dann hoffentlich alles Kontrollieren und ansteuern.

Die Idee mit den Tastern hatte ich auch schon mal (und bei Phoenix 2 sogar schon angelegt), allerdings werd ich eher auf Neigungssensoren umsteigen um den Roboter immer in der geraden halten zu können.


4 Trigonometische

[MeckPommER]

Nun, das mit den 20 Trigs wird etwas eng (eine Drehung eines Punktes um alle Achsen braucht ja schon 3*sin+3*cos), zumal die ja nicht alles sind. Da kommen ja noch Fliesskommaberechnungen ... *koppkratz* ... nun, es ist auf jeden Fall einen Versuch wert! Hat ja auch seinen Reiz, zumal das geringe resultierende Gewicht auch ein schöner Lohn ist!
Drei Piezo-Gyros liegen auch bei mir und warten auf ihren Einsatz. Sind damals übrig geblieben von meinem Ufo-Bau. Obwohl ... eigentlich braucht ein Hexapod ja nur zwei Gyros, die Drehung um die Y-Achse kommt ja nicht von unebenen Boden und braucht ja auch nicht ausgeglichen zu werden.

Unebenen Boden/Löcher ausgleichen, Gyroskope, Terrainwiedererkennung, KI, dütt und datt ... ist es nicht herrlich, das man an so einem Teil bis zur Rente wurschteln kann ^^

Vielleicht bist du ja auch mit einem arm7 oder so besser bedient, der um einiges flotter ist?

[BeautyofBaud]

Sehr schöne Sache =) der rockt der Bot....

Leider werd ich wohl so´n Ding eher nicht bauen können nachdem was ich da an Sachen gelesen hab....

Wie ich Mathe hasse *g*
... Ich glaub soviel rechnen würd ich nich überstehen

aber RESPEKT

greEtz Baud

[MeckPommER]

Siehste ich mag auch nicht rechnen ... darum überlege ich mir nur, wie es theoretisch gemacht werden müßte und das Rechnen übernehmen dann die Mikrocontroller

Gruß MeckPommER

[BeautyofBaud]

hehe ... Naja aber die ganze Theorie ist böse... ich neige dazu mich bei sowas zu langweilen ... naja dann ist die Leistung schonmal um ööhm 99,9999999999... % herrabgesetzt...


Allerdings durfte ich mir da schon Einiges zu anhöhren - vorallem wenn ich wegen ner Veranstalltung an einer Uni war oderso, frei nach: "Was du programmierrst usw.... aber magst kein Mathe ... das Geht?"

Vielleicht liegts auch nur an meinem derzeitigen Lehrer...

Aber das Ding ist echt der Hammer... Ich bin froh, wenn ich überhaupt meine Bilderkennung auf die Reihe kriege... andere Geschichte...

Hat eigentlich mal jemmand von euch den Hexa von der Uni-Lübeck gesehen? Hab letztes Jahr die erste Schulwoche "geschwänzt" und da ne Art Praktikum gemacht.

Das Ding ist ziemlich lustig... Die haben dem ein Paar "Regeln" übergeben und dann überlegt sich das Viech, wie es die Beine bewegen muss um nicht hinzufallen.

[Asurokiller]

Wie steuerst du den Bot?
Per Funk
Oder
mit Kabel