MeinHexapod: "SEXCRORA"

[MeckPommER]

Fein, fein, fein

Ich freue mich riesig, das in letzter Zeit nicht nur einige meinen, sie würden mal eben den perfekten Hexa bauen, sondern das mehr und mehr Hexas tatsächlich auch entstehen.
Bei vielen bleibt ein Hexa irgendwo in der Planung oder dem Portemonais stecken und kommt niemals heraus

Das du keine MG995-Servo verwendest, erspart dir einiges an Zittern bei denem Bot, wenn du auch dafür mehr auf das Gewicht deines Bots aufpassen musst.

Das mit der IK war bei mir nicht anders: erst muss sie funktionieren, dann wird sie erweitert.
Diese Erweiterungen waren bei mir ähnlich wie bei dir: unterschiedliche Schritthöhen der Beine, unterschiedliche Geschwindigkeiten, etc.

Eine Erweiterung der IK, die ich wirklich jedem Hexabauer ans Herz legen kann, ist eine variable Beinsequenz beim Schreiten. Es gibt einfach keine Schrittfolge, die immer passt. Wenn der Hexa sich auf der Stelle dreht, machen die mittleren Beine nur kurze Schritte, während die äußeren Beine kaum hinterherkommen und so weiter.
Da dies eine starke Erweiterung ist, wollte ich sie möglichst früh in deinem Projekt erwähnt haben, damit du später nicht so viel umwurschteln musst, falls du ähnliches machen möchtest.

Gruß MeckPommER

[WarChild]

@ Meckpommer

Auf deiner Seite ist der Bus leider nicht gepostet
Wie breit ist dein Bus und was ist darauf verfügbar?
Denn deine Steckkarten haben ja doch reichlich Anschlüsse.
Ich bin nämlich auch am überlegen, wie ich die ganzen daten transportiere, alles nur über I²C ist wohl zu viel verlangt.
Hast du einen parallelen Bus, oder einfach nur sehr viele Signale auf den Leitungen zur verfügung stehen? (Interrupts, sensoren, TWI, Spannungsversorgung...)
Was hast du als MASTERBRAIN in deinem Hexapod?

mfg WarChild

[MeckPommER]

@ WarChild

Der Bus ist 2*8 Bit breit: 8 Bit vom Master zu den Untercontrollern und 8 Bit zurück. Ein Bus a 8 Leitungen besteht aus jeweils 4 Datenleitungen und 4 Steuerleitungen. Programmiert ist der ganze Datentransfer in Assembler und ich erreiche Datenraten etwas über 1MBit bei absolut 0 Datenverlust. Das Protokoll ist so ausgelegt, das Sender- und Empfängercontroller nicht gleich getaktet sein müssen.

Ferner sind auf dem Bus noch 5V, 7.2V, 11.1V, Reset und zwei "freie" Leitungen.

Über diesem Bus geht alles an Daten, was mein Bot so verhackstückelt. GPS-Daten ebenso wie Bilder von den Kameras, Inhalte des 512KB-RAM, Gyrodaten, etc. Ich habe mir ein Protokoll geschnitzt, bei dem jede Funktionseinheit eine Gerätenummer hat, an die ich Daten senden, oder von der ich Daten empfangen kann.

Masterbrain meines Bots ist ein Atmega128. Ich achte aber darauf, das er möglichst wenig zu tun hat und nur gut vorverdaute Daten bekommt. So bekommt er z.B. vom Kameramodul keine Bilder zur Analyse, sondern gleich z.B. bei der Laserentfernungsmessung nur die Entfernung zum anvisierten Punkt.

Auf den Steckkarten sitzen stets Controller Atmega16, 32 oder 644 - eben damit die Controller noch genug IO-Pins für ihre Aufgaben zur Verfügung haben.

Gruß MeckPommER

[WarChild]

Danke Meckpommer. Dein Bot hat ja schon ein paar evolutionen hinter sich, da finde ich es nur ratsam, aus deinen Erfahrungen zu lernen, anstatt später festzustellen, das irgendwas vorne und hinten nicht ausreicht.

Da ich weiß wie sehr alle Videos lieben:
Hier ein kurzes Demo. Er läuft einfach nur eine hinterlegte bewegung step by step ab. Die Bewegung besteht nur aus 240 Werten für die drei Winkel.
Die Stromaufnahme schwankt zwischen 3 und 5 A

LINK
[flash width=425 height=350 loop=false:54e4372620]http://www.youtube.com/v/MhhHbyjWLwg[/flash:54e4372620]


Ich hoffe es gefällt euch.
mfg WarChild

[ikarus_177]

Hi,

sieht ja schon sehr sauber und flüssig aus!

Sind das "nur" vorher getestete Positionen, die er nacheinander abfährt, oder berechnet schon die IK die Winkel für alle 18 Servos?

Mach nur weiter so!

viele Grüße

[WarChild]

Hi,

Die postionen sind ein durchlauf der x-Achse von 10 bis -10, beim vorlauf ist z konstant -10 und beim rücklauf steigt z linear auf -5 und dann fällt es wieder auf -10. y ist konstant 8. die figur ist ein gleichschenkliges Dreieck, auf dem der Fußpunkt entlang läuft.

Die Winkel habe ich entsprechend der obigen Figur vorab von Excel berechnen lassen und dann einfach in kommagetrennter schreibweise speichern lassen. STRG+C, STRG+V fertig war die erste Bewegung.
Die funktionen die Excel ausführt muss ich jetzt noch in den Atmega implementieren.

Habt ihr Vorschläge, wie man möglichst schnell acos(), asin(), atan() berechnen lassen kann? oder sollte man das am besten als Tabelle hinterlegen?
sin() ließe sich einfach als Tabelle machen. 1-180° entsprechen den einträgen 1-180 eines Arrays. Bei asin() ist das problem, dass die Eingabe werte zwischen -1 und 1 liegen.

Mein µController ist jetzt alle 10ms damit beschäftigt 9 Servosignale zu erzeugen. (Mehr als 14 waren bei einer 8µs Auflösung nicht möglich, daher werden immer 9 Signale im 10ms Wechsel erzeugt). In der Zeit ist er fast völlig vom Interrupt0 ausgelastet, sonst ist der Interrupt0 aus. Also müssen in den 2*7,5ms zwischen der jeweiligen impulserzeugung je neun Winkel berechnet werden. Und in Vorraussicht, muss ich auch noch genug Zeit haben, 18 Bytes via I²C zu übertragen, was rechnerisch ungefähr 1,5ms dauert bei 100kbit/s.
Das heißt die Berechnung muss schnell sein. Die Koordinaten werden jeweils mit Ursprung im Schultergelelnk übermittelt. Die Berechnung jedes artgleichen Winkels (Schulter/Oberarm/Unterarm) lässt sich also auf je 6 Winkel anwenden. Die Umrechnung auf die Absoluten Koordinaten mit Ursprung im Schwerpunkt des Roboters macht der gleiche µC, der auch die Bewegungsabläufe steuert.
Ich denke da werde ich einen nehmen, der Zwei I²C kanäle hat. Einer exklusiv für die Beinkoordinaten, damit der garantiert nicht blockiert, denn es ist der wichtigste Datenweg.

mfg WarChild

[raoul4]

Hey, das sieht wirklich sehr schön aus, wenn das so flüssig vonstatten geht. So etwas sieht man nicht oft.
Saubere Arbeit!

mfg

[MeckPommER]

Also das mit den Sinus- bzw. sonstigen Tabellen ... das hat bei mir stets einen faden Nachgeschmack hinterlassen. Damit Bewegungen sanft und präzise verlaufen, muss so eine Tabelle schon eine enorma Auflösung haben. 1 Grad-Schritte sind da bei weitem noch nicht ausreichend. Da einem aber schnell der Speicher ausgeht (RAM oder EEPROM) muss man sich damit behelfen, nur einen kleinen Teil der z.B. Sinuskurve in der Tabelle zu halten und den Rest per Symmetrien zu ermitteln (große Teile so einer Kurve spiegeln sich auf die eine oder andere Art).
Dies wiederum bewirkt, das man nun je nach Wert die Ergebnisse der Tabelle auch wieder bearbeiten muss, kurzum: für mich hat es sich nicht gelohnt, auf Tabellen umzusteigen. Ich bin nach meinen Tabellenexperimenten wieder zu den eigentlichen Funktionen zurückgekehrt. Auch hier war (zumindestens bei mir) einiges am Programmcode optimierbar.
In meinem Bot macht ein Atmega128 die komplette IK UND Servoansteuerung für 6 Beine/18 Servos bei einer Refreshrate von ca. 42-50 Hz.

Gruß MeckPommER

[WarChild]

benutzt du die math.h oder selsbt geschrieben funktionen für sinus...
wenn so ein µC in der lage ist die fertigen, exakten funktion in der geschwindigkeit zu hantieren, dann brauche ich mir ja keine gedanken zu machen.
edit: hab gerade deine seite bezüglich der Berechnungen gefunden.

mfg WarChild

[hunni]

Wirklich schönes Teil!!! Respekt. Nur eine Sache hätte ich vielleicht zu bemängeln, das nämlich die Servos wahrscheinlich auf dauer zu arg belastet werden. Damit miene ich nich die Stellkraft, sondern die innere Mechanik wird wahrscheinlich zu arg beansprucht. Diese sind für den Modellbau deswegen geeignet, da sie ziehen und drücken. Nun gut das tuen diese zwar auch, aber es gibt keine übersetzung oder Hebelarme.
Kann mich natürlich auch nur täuschen und das Ding hält Jahrzehnte.