Hexapod - "IKU"

Hallo Community,

hier stelle ich Euch meinen fast fertigen Hexapod "IKU" vor.

Ich orientierte mich dabei an Matt Denton's "i.c. - Hexapod".
Den finde ich immer noch "megageil"

Alle Aluminiumteile sind von mir in Handarbeit angefertigt worden. Alle Bohrungen sind mit Handbohrmaschine erstellt.

In der Mitte des Körpers ist der LiPo Akku (7,4V 3700/3600mAh 20/30C) vorgesehen.
Als Antriebe sind 12x digitale HS-5645MG und 6x analoge HS-645MG verbaut.

Bei der Programmierung setze ich auf BASCOM in der Vollversion.

Eine Mega328-20MHz berechnet momentan die Werte der inversen Kinematik, welche per I²C an eine SD-21 Servocontrollerkarte geschickt werden. malthy's Hexapode - inverse Kinematik Dokumentation hat mir diese komplexe Thematik näher gebracht.
Allerdings habe ich noch keinerlei Kollisionsprüfung programmiert.

Die Akkuspannung wird überwacht, und die Servospannung wird per Relais abschaltbar sein.

Die grundlegenden Abmasse sind:
Bein: Coxa = 24mm; Femur = 65mm; Tibia = 112mm
Körper: Servoabstand nach hinten = 85mm; Servoabstand links zu rechts 81mm (vorne/hinten) und 101mm in der Mitte.
Mit diesen Maßen passt er also mit angezogenen Beinen auf ein DIN A4 Blatt - nun ja, ich gebe zu eine Rennmaschine wird es so nie werden ;)

Die relevanten Abweichungen der jeweiligen Längen in den Oberschenkeln (Femur) hält sich mit maximal 0,4mm in Grenzen.
Auf eine Gegenlagerlösung habe ich hier bisher bewußt verzichtet (vorerstmal).
Der Unterschenkelabschluss (Fussansatz) muss jeweils noch in der Länge angepasst werden - da habe ich deshalb auch keine besonderen Wert auf Masshaltigkeit gelegt.
Dort ist noch eine Art Adapter als Fuss geplant. Dieses Element ist aber noch nicht genauer definiert um es zu zeichen. Vielleicht zerteile ich den Unterschenkel dafür nochmal. Gummi oder Silikonüberzug bekommt es aber bestimmt.

Das Bild zeigt den aktuellen Baustatus im Vergleich zur CAD Zeichnung (ausgeblendete Elemente):

Anhang 25233

Ein komplettes Bein wiegt 232g ( inkl 3x60g für Servos) = 6 Beine zusammen = 1392g
Die Unterplatte wiegt ca 100g. Die Oberplatte ist noch nicht fertig, aber wird nicht mehr als ca 150g - darin werden dann auch Gegenlager mit Kunststoff Kugellager für die Hüfte eingebaut sein. Diese sollen, um meine Fertigungstoleranzen auszugleichen, einstellbar werden.

Dazu kommen noch die Absandhalter der Körper-Unterplatte und -Oberplatte. Und die Oberplatte selbst. 1x Relais + µC BabyO-328 und SD-21 sowie der LiPo Akku (und der extra µC Mega8-1Mhz zur Spannungsmessung).
Die ganze Elekronik wird nachher auf die Oberplatte montiert.

Einige der genannte Punkte sind noch in arbeit z.B. werde ich die Akkus morgen noch wiegen damit ich das Gewicht auch habe.
Ich erwarte ein gesundes Gesamtgewicht bei der momentanen Planung von nicht mehr als 2500g.

Anfang Dezember'12 habe ich konkret mit der Planung begonnen, bei ungefähr jeden Tag 1h CAD Entwurf in Sketchup und anschliessender Materialbearbeitung.

Ich bin genauso gespannt wie Ihr ob das alles so hinkommt.

Habe ich was wichtiges vergessen zu erwähnen? - sicher habe ich das ;)

Bei der Konstruktion würde ich fürchten, dass - wegen der fehlenden Gegenlager beim Oberschenkel - das System sehr leicht tordiert und wackelt. Soweit ich Matts Hexa kenne, hat er das Problem umgangen indem er auf die Servoaufsätze verzichtet und die Oberschenkel direkt am Servohorn anschraubt. Auf jeden Fall wird man Metall-Servoaufsätze verwenden müssen und Servos mit einem Metall-Servohorn. Plastik wird hier zu schnell "ausnudeln" und ist zu weich. Das ist auf den Bilder nicht ersichtlich, aber die Servobeschreibung sieht nur einen Nylon-Aufsatz vor. Das wir man leider erst bei der Programmierung merken, wenn der Roboter dann "wackelt".

Die Servos am Fuss nur an einer Lasche anzuschrauben finde ich ist zu wenig. Auch Matt hat hier zwei Schrauben pro Seite, also vier pro Servo. Das gibt dem ganzen einfach mehr Stabilität.

Das Gewicht ist erstaunlicherweise gar nicht so viel weniger als bei meinem Vinculum-Beinen, nur 50g. Ich hätte erwartet dass es mehr ist, aber sieht wohl so aus als hätte ich gut konstruiert.
Zumal mein Gesamtgewicht bei 2,7kg geplant ist und ich viel mehr "drauf gebaut" habe. Interessant die verschiedenen Bauweisen bzgl. Gewicht zu vergleichen.

Bezüglich der Elektronik:
- Es gibt tolle ICs auf dem Markt die genau einen Job haben: Spannung und Strom zu messen und als i2c Signale bereit zu stellen. Das würde den zweiten Mega8 sparen. Für mein Vinculum hab ich mir jetzt welche bestellt ich wollte sogar 7 Stück einbauen (einen pro Bein und einen für die Akkuspannung), doch leider hat der Chip nur 4 mögliche Adressen, daher gehts nicht.

- Bitte beachten, dass die Servos nur für 4,8V-6V ausgelegt sind. Alles darüber wird bei Markenservos gehen aber bei digitalen kann das schon Probleme machen. Die Elektronik im inneren steht nicht so auf Überspannung. Zumal die meisten Logikbausteine für 5V ausgelegt sind.

- Bei LiPo Akkus empfiehlt es sich einen Akkuwächter einzubauen, der unabhängig von der Logik agiert und den Akku "rettet" bevor er in Unterspannung fällt. Einen Akku habe ich schon auf dem Gewissen weil ich die Spannung nur über die Logik überwacht hatte.

PS: Meine Bauzeit mit CAD und Co ist allerdings schon viel viel länger.

Ja, ich habe mir Matt's i.c. auch genau angesehen: Leider ist es mir aber momentan nicht möglich die Splineaufnahme direkt ins Alu zu bringen. Tatsächlich habe ich die Nylonscheiben mit beidseitigen Aluplatten eingespannt um die Flächenverformung der Scheibe zu minimieren. Der Nachteil der restlichen Torsion werde ich mir ansehen. Ansonsten finde ich das es dadurch auch eine gewissen Dämfung gibt damit Stöße nicht komplett ins Servogertriebe übergehen.

Die Bauweise des Körpers z.B. habe ich gewählt um flexibler bei Änderungen zu sein. Ich verlängere lieber die L-Profile, oder die Querhalter als mal eine komplett neue Platte anzufertigen (bzw anfertigen zu lassen). Auch hatte ich eine weitere Querplatte unter der ersten geplant, die habe ich allerdings erstmal ignoriert - diese wird nachträglich angefertigt falls das bisherige sich merklich verformen sollte.
Der gleiche Ansatz ist bei den Gegenlager im Oberschenkel geplant falls es sich zu stark verformt. Im Oberschenkel ist quasi schon ein Blech drin, welche fürs Gegenlager genutzt werden kann. Auch der Abstand der Servos lässt es zu eine Verstrebung einzuziehen. Die Bohrungen sind dafür vorbereitet.

Ich habe keinen Erfahrung mit den IC's die du vorschägst, aber ich habe schon Spannungen gemessen mit Mega8, dann kann ich damit auch gleich den Strom trennen lassen. Sicher nicht die beste Lösung, aber es ist eine - eine die ich auch bauen kann ;)
Bei dem LiPo messe ich die jeweilige Zellespannung direkt am Balancer Anschluss - auch über Transistoren gesteuert nur alle paar Sekunden.

EDIT: Meine beiden LiPo' s wiegen um und bei je 230g - ich hatte dafür mehr eingeplant, da freu ich mich doch\\:D/

Die Alumaterial ist übrigens durchgehend 2mm stark.

Hallo HeXPloreR

Endlich mal wieder ein ALU-HEXAPOD
WOW!!
Ich finde deine Konstruktion toll !!
Etliches, was ich damals bei meinem SENSOBOT verwendet habe, finde ich bei Dir wieder.
Bin gerade dabei einen runden HEXAPOD zu bauen, der mit einer Software für BASCOM laufen wird, die man auf jedem selbstgebauten HEXA anwenden kann.
Du gibst nur die Werte für die Schenkellängen und die Körperabmaße ein und der Bot läuft.
Wünsche Dir weiter viel Erfolg

MfG

Roland

Vielen Dank Roland für das Lob.

Diese Anpassungen habe ich auch geplant, nur erstmal nicht weiter verfolgt da ich ja noch am Hexa arbeite. Ich wollte es dann in einen Selbsttest packen, wo abgefragt werden soll ob die Längen der Beinsegmente noch zutreffen - angezeigt auf z.B. LCD oder Terminal. Dort sollte man ändern können, wenn man möchte, und die Werte werden dann ins Programm übernommen.


Ich wünsche auch Dir viel Erfolg weiterhin.

EDIT: Bevor ich es vergesse zu sagen, das war geplant um es auch bei meinen Bioloid "EVA" anzuwenden, allerdings bin ich mit der Ansteuerung der Dyx's mit "nicht Original Mikrocontrollern" noch nicht recht vorangekommen.
EDIT2: Man darf auch nicht vergessen das nicht nur die Längen bei der Kinematik interessant sind, sondern auch welche Ausdehnung sie haben. Da wird es dann schon ggf unübersichtlich das alles in ein Menü einzugeben.

Ich bin auch der meinung das mir Dein SENSOBOT im Netz auch über de Weg gelaufen ist - möglich das sich die Rahmenkonstruktion auch deshalb bei mir festgesetzt hat ;)

Hallo HeXPloreR,

alle Achtung, ein hübsch umfangreiches Projekt - und schon ne Masse Arbeit die Du reingesteckt hast.

Zitat:

---

... meinen fast fertigen Hexapod "IKU" ... Ich orientierte mich dabei an Matt Denton's "i.c. Hexapod" ...

---

Hat Du eine Vorstellung davon, wie/womit die Gesichtserkennung bei dem Hexapod von Matt Denton funktioniert? oder funktionieren kann? Bei micromagicsystems.com steht "... pan/tilt head that includes a CCD video camera linked to an off board PC running face recognition software ...". Mich würde ein bisschen so ungefähr der Umfang interessieren - Umfang hard- und softwaremässig. Und eher nur aus Interesse *ggg*. Gibts nicht schon "embedded" Cams mit Gesichtserkennung - ohne dass ein Rechner dran hängen muss? Zumindest mit ner Art Gegenstandserkennung?

Hallo oberallgeier, danke Dir.

Ja das sind gute Fragen ;) - es gab da so eine CAM irgendwo, mir fällt der Name grade nicht mehr ein, 3.Version oder so...die Gesichter erkennt oder auch Farben im Raum suchen kann...ob die zusätzlich noch was benötigt? Keine Ahnung.
Zum Zitat muss ich sagen das ich mich vorrangig an der Idee der Bewegungsumsetzung von "i.c." festgemacht habe. Nicht explizit an Gesichtserkennung oder upload von Bilder. Und dazu selbstverständlich diesen schönen Körperbau abgeguckt habe.

Zu IKU kann ich nur sagen das sie einen Kopf bekommen wird. Ich habe Sharp Infrarot Sensoren und eine (Funk)Kamera eingeplant. Gesichtserkennung steht bei mit noch nicht an - wenn überhaupt.

Matt's i.c. sieht für mich aus wie eine Ballerina ;) - sollte ich irgendwann in den Genuss kommen einen neuen schöneren Körper aufzubauen, dann werde ich es ganz genauso aussehen lassen. sweet :cheesy:

Boahhh...ich könnte brechen... schon wieder ein Empfänger der sich abgemeldet hat. Ich habe ja echt kein Problem damit wenn die Dinger keine 11V aushalten und es somit einfach meine eigene Schuldselber ist. Aber dieser hier geht von der einen auf die nächste Minute einfach nicht mehr - für mich gab es hier keinen ersichtlichen Grund warum der seinen Dienst einstellt. Den werde ich also beim großen C vorbei bringen, ist grade mal 2 Monate her wo ich den gekauft habe. Ich bin enttäuscht.

Mein Programm zeigt mir den Empfang im Terminal an, und plötzlich steht da: RC = 0 ' *brechreizunterdrück*

Kurze Info zur inversen Kinematik:

Im momentanen Programm ist die eigentliche Berechnung für ein Bein über knapp 40 Zeilen Code verteilt. Da man in Bascom nicht mit Klammern arbeiten kann sind die Berechnungen manchmal etwas umständlicher als z.B. in C. Die Berechnung startet jetzt noch an der ersten Beinachse - in der Hüfte - mit dem empfangenen RC-Werten. Später wird diese Berechnung aus der Körpermitte zu den Beinen verteilt werden. Dazu wird die Berechnung der inversen Kinematik nicht erweitert, sondern eine weitere die aus der Körpermitte bis zur Hüfte berechnet angehängt. Die Zuweisung der berechnetet Werte soll dann in eine Schleife mit Zuweisungszähler usw ablaufen.

Der Code für die Berechnung eines Beins hat knapp an der 4kB Codegrenze der Demoversion gekratzt. Ich habe optimiert wo ich es gesehen habe, und möglich war. Einen Wert lasse ich z.B. vorab berechnen, da dieser sowieso aus zwei Konstanten besteht. Allerdings habe ich die Werte später nicht an die SD-21 übergeben können, da das dann die Einbindung der SD-21 über I²C im Programm erforderte, was dann zu viel war. Deshalb die Vollversion.

Ein klitze kleines Fehlerchen habe ich in malthy's Doku für mich im Bildmaterial korrigiert und erweitert. Auch hat sich ein genannter Lösungsweg für mich nicht plausibel erschlossen, da habe ich einen Anderen gewählt, der aber genauso auch mit Winkelergänzungen arbeitet - wohl nur andersrum geht ;)
malthy möchte ich auch an dieser Stelle für die wirklich gute Erklärung der Thematik danken.

Zitat:

---

Zitat von HeXPloreR

.. schon wieder ein Empfänger der sich abgemeldet hat...*

---

Vielen Dank an die Mitarbeiter vom grossen C - mein defekter Empfänger wurde anstaltslos gegen einen Neuen umgetauscht. Das ganze hat keine fünf Minuten gedauert ... als ich dann endlich mal dran war, und man das vorherige quer durch den Laden gelatsche mal wegläßt ;)

Ich bearbeite grade die Oberplatten und die Abstandshalter in meiner "Fachwerkstatt" im Keller :cheesy:

Jetzt hoffe ich, das ich bis Sonntag die Zeit finde, weiter aufzubauen und die ersten Bewegungen zu programmieren.

Hallo Hexplorer!

Schön dass ich mal etwas Feedback zu meinem Ansatz bekomme! Ich muss nochmal genau reingucken, so auf den ersten Blick versteh ich noch nicht ganz, wo der Fehler steckt. Aber vielleicht schreib ich dich auch einfach mal per PN an, dann machen wir deinen Thread hier nicht mit irgendwelchem Offtopic-Kleinkram kaputt. Sollte ein echter Fehler in meinem Artikel sein, will ich den natürlich noch korrigieren ...

Bei mir ist die IK noch etwas länger, ich habe 54 Zeilen gebraucht. Ich habe allerdings auch versucht so "explizit" wie möglich zu programmieren, einfach um das Verständnis zu erleichtern. Es gäbe da bestimmt noch Optimierungsbedarf. Du verwendest vermutlich auch Gleitkommaarithmetik, die frisst ja immer Platz (und Zeit). Wenn man die rausschmeißen würde, bekäme man die Sache bestimmt noch komapkter und schneller. Naja, den Ehrgeiz hatte ich damals nicht, da ich noch analoge Servos verwende, bei denen die Updaterate ja eh nur bei 50 Hz liegt.

Also so oder so: vielen Dank für's Feedback und ggf melde ich mich nochmal bei dir. Ansonsten bin ich gespannt auf den Fortschritt deines Projektes!

Gruß
Malte

Hallo Malthy,
ist nur was klitze kleines (kein echter Fehler) - kein Grund zur Beunruhigung ;) Ändert nichts daran das es gut funktioniert mit Deinen Erklärungen.

Ja, benutze Single-Variablen. Leider ist das erstmal der einfachste Weg für mich, sollte es damit (Zeit)Probleme geben muss ich wohl nachbessern. Oder auf mehrere µC ausweichen.
Momentan beschicke ich eine SD-21 über I²C - soweit ich weiß, aktualisiert die auch nur alle 20ms. Allerdings halten die Digital Servos in der Zeit dazwischen ihre Position, wärend man bei den Analaogen genau merkt wann sie ihr Signal bekommen. Die habe ich aber nur in der Hüfte (Coxa-Servos) eingebaut, da sollte es kaum zu merken sein im Betrieb.

Ob ich wohl zwei oder drei normal arbeitende µC - also nicht als Slave's - an den I²C Bus hängen kann, und die zirkulär auf den Bus zugreifen lassen könnte? Sollte ja gehen, wenn man die Sendetermin per Freigabe mit einem Pin auf High steuert. Hmm, muss ich mir mal genauer überlegen.

Wenn man Gleitkommas rausschmeisst, muss man dann nicht mit noch gößeren Zahlen (bzw Variabken) rechnen? Daher dachte ich es schadet dem Verständniss nicht, wenn es erstmal damit läuft. Da hat man schonmal einige Fehlerquellen aussen vor gelassen. Hoffentlich.

Ich habe nichts gegen OT - vor allem wenn es keines ist ;)

Ich bin genauso gespannt ob das alles so klappt - vielen Dank Dir auch.

Die Gleitkommazahlen braucht man ja auch wegen der Trigonometrie, die Funktionswerte kann man ja nur in Singles schreiben. Und die entsprechende Library (FP_TRIG) nimmt dann auch noch Platz weg. Ich habe vor kurzem mal eine Implementierung eines CORDIC Algorithmus in Assembler für Bascom verwendet (nicht von mir implementiert), damit kann man dann auf Singles verzichten und auch auf die FP_TRIG Library. Ging eigentlich problemlos. Ich bin auch immer versucht mich nochmal wieder an meinen Hexa zu setzen, dann würde ich es glaube ich mit dem CORDIC Ansatz machen. Habe das Projekt ja nie wirklich zu Ende - oder sowas ähnliches - gebracht ... :-)

CORDIC-Algorithmus? - okay, sieht nach viel Grundlagen lesen und verstehen aus. Ich denke aber auch diese Annäherung reicht völlig aus, vor allem wenn man die Auflösung der Servos bedenkt - und die PWM(Positions)werte wieder Ganzzahlen sein müssen. Ist gemerkt. Vielen Dank für diesen Hinweis.

Ich muss gestehen, das mich die Informationsflut im Netz das eine oder andere Mal doch recht verwirrt hat. Bis ich diese Projekt angefangen habe, um mich genauer auszurichten und gezielter Informationen zu finden. Anstatt mal irgendwie alles so halb gelesen zu haben und davon dann auch nur einen kleinen Teil verstanden zu haben.
Vermutlich war der CORDIC-Algo da schon irgendwann mal mit bei, aber wenn man noch nicht weiß was damit anzufangen ist dann tut man den wohl eher einfach so ab. Der scheint tatsächlich alles zu beinhalten was nötig ist. Schiebeoperationen habe ich in diesem Zusammenhang jedenfalls schon mal gelesen.

Ich denke wenn man erstmal Deine Erklärungen so weit verstanden hat, kann man das auch gut mit CORDIC abarbeiten. Ich muss nur aufpassen, denn ich habe die Achsen getauscht - ich komme mit der Z-Achse als Höhenachse besser klar ;)

Hallo Zusammen,

ich habe nun den mechanischen Aufbau so weit abgeschlossen das die ersten Korrektur-Parameter an allen linken Beinen eingestellt werden konnten.
Demnächst folgt die rechte Seite.

Das Gewicht beträgt in dieser Ausbaustufe jetzt ca 2kg. Es fehlen immer noch die eigentlichen Füsse und ein erster Kopfentwurf.

Als Füsse werden vorläufige Teile gefertigt und die dann erstmal eingebaut.

Hier sind einige neue Fotos:
Anhang 25527Anhang 25528Anhang 25529Anhang 25530Anhang 25531

Sieht ja schonmal schick aus, aber kann die Körperstruktur sich nicht verknicken? So, wie es jetzt ist, ist der Rumpf ja eine Konstruktion aus Parallelogrammen und könnte sich theoretisch an den Verschraubungen wegknicken. Zwar wird es sicherlich nicht wirklich stören, aber ich hätte wahrscheinlich etwas eingebaut, was den Rahmen in sich fixiert. Dann ließe sich dieser auch besser zusammenschrauben, ohne es dann noch ausrichten zu müssen.
Die Gegenlager sehen übrigens interessant aus, wie funktionieren die?

Zitat:

---

Zitat von Geistesblitz

Sieht ja schonmal schick aus... was den Rahmen in sich fixiert.... besser zusammenschrauben, ohne es dann noch ausrichten zu müssen.
Die Gegenlager sehen übrigens interessant aus, wie funktionieren die?

---

Vielen Dank Geistesblitz für Dein Feedback,

ich habe in dem unteren Plattenrahmen nach dem ausrichten zusätzlich 1x eine 3mm Bohrungen durch die Überlappungsbereiche gebohrt. Beim erneuten zusammenbau wird da mit dem Schaft vom Bohrer ausgerichtet. Oben habe ich diese "Ausrichtungsversuche" noch nicht eingebohrt. Allerdings ist diese Art auch nur für den Zusammnebau gedacht, und nicht auch im Betreib - daher könnte es sich wirklich wieder verschieben 8-[.
Ich weiß das ist nicht "State of the Art". Ich würde lieber zweimal 2mm Paßstifte an diesen Stellen benutzen, nur kann ich das nicht herstellen bzw ich habe es auch noch nicht versucht.

Die Gegenlager funktionieren so, das sie die Servoachse frei geführt parallel in der Bohrung halten. Eine Begrenzung nach oben hab ich in meinem ersten Alustreben gehabt - allerdings geklebt (Fotos) - damit ist das Gegenlager nicht so leicht ausbaubar wie es jetzt ist. Das habe ich hier erstmal nicht angebracht. Es wird wenn nötig dann zusätzlich anschraubbar werden - damit es einfach demontierbar bleibt. Es wird eine einfache zusätzlich Schraube mit "Unterlegscheibe" sein um den Rand des Lagers in der Bewegung zu begrenzen.

Erstes Version des Gegenlager 10mm/9mm:Anhang 25532 und hier von unten, sieht man den Bund besser:Anhang 25533
Die ganze Befestigung des Teils war anders gedacht, die habe ich aber verworfen.

Hättest di Befestigung ja gleich mit jeweils 2 Schrauben planen können, dann würde es sich definitiv in seiner Form halten. Jetzt könntest du aber was machen, und zwar eine oder mehrere Diagonalstreben irgendwo reinziehen. Durch die Länge sollte es dann auch einigermaßen genau bleiben, da sich dann ja kleine Abweichungen kaum noch auswirken.

Zitat:

---

Zitat von Geistesblitz

Hättest di Befestigung ja gleich mit jeweils 2 Schrauben planen können, dann würde es sich definitiv in seiner Form halten. Jetzt könntest du aber was machen, und zwar eine oder mehrere Diagonalstreben irgendwo reinziehen. Durch die Länge sollte es dann auch einigermaßen genau bleiben, da sich dann ja kleine Abweichungen kaum noch auswirken.

---

Qoersteben? Vielen Dank für die Idee, die könnten ihren Platz nur zwischen den Gegenlagerstreben finden. Dann könnte ich diese direkt so fertigen das sie auch etwas zur Einstellarbeit leisten könnten. Ich überleg auch ob die direkt in die Gegenhalterstreben besser passen würden.

Zwei Schrauben wäre mir immer noch zu ungenau um es wieder ohne Ausrichtung zusammen zu bauen. Hatte ich erwähnt das es anders geplant war. Und die L-Profile darunter schon gefertigt waren, mit den Bohrungen ;)

Ich favorisiere eher eine Art Verstiftung, mit 2 Paßschrauben oder Senkkopfschrauben an jedem Überlappungspunkt könnte man arbeiten. Kann ich aber leider nicht herstellen.

Hier mein Testvideo: IKU - erste Bewegungen mit inverser Kinematik (1:49)

Hmm, irgendwie zittern und zappeln die Servos teilweise noch stark. Ich denke mal, dass da irgendwas das Signal stört, aber was es ist musst du wohl selber herausfinden.
Die inverse Kinematik funktioniert ja aber schon ziemlich gut, hast du auch schon andere Bewegungen probiert? Also zB. seitwärts, vertikal oder verkippen im Raum.

Das sieht doch schonmal sehr gut aus! Das Zittern kann natürlich auch stumpf von einem zu knappen Netzteil herrühren. Ich habe damals ein ATX Netzteil verwendet, die könmnen naturgemäß hohe Ströme liefern. Was verwendest du für ein NT?

Hey, vielen Dank für die positiven Rückmeldungen.


Soweit ich das gestern gesehen habe ist es nur der erste Servo im Bein #4. Ich vermute das der LiPo Akku zwar die Leistung bereitstellt aber sie nicht recht dort ankommt. Es scheinen Spannungeinbrüche zu sein, vermutlich zu dünne Leitungen.
Ich werde den Servo bzw das Bein heute abend separieren und mit verschiedenen Versuchen das Problem einkreisen und wenn möglich beheben. Leider habe ich nur ein Multimeter - also muss ich "stumpf nach Augenmass" gehen.

Ich habe bisher nur diese Bewegung, als nächstes kommt die Bewegung zur Seite - mal gucken wie lange ich heute daran weiter mache - das letzte Wochenende war irgendwie doch noch zu kurz ;)
Das Problem ist, ich habe momentan nur eine 4-Kanal Funkfernsteuerung ... da bleibt nachher nur noch ein Kanal übrig :(

Das ist doch schon mal ein großer Fortschritt bei deinem Projekt. Spürst du vielleicht so etwas wie Termindruck, der auf dir lastet? Wg. der Maker Faire im August ;).
Weiter so.
Irgendwann muss ich mich auch mal mit solchen Krabbel Robotern befassen.

Zappelnde Servos bei Hexas sind doch fast schon ein Standard Problem. Nicht, dass ich sowas nicht auch schon 100mal gehabt hätte.
Hier die gängigen Lösungstipps:
1) 100Ohm Widerstand in der Signalleitung
2) Kondensatoren im Leistungsteil, hier verwende ich beim Vinculum 6x6800µF für jedes Bein und nochmal ein paar Kleine für die Spannungsspitzen
3) Signalleitungen und Spannungsversorgung getrennt verlegen.
4) Ferritkerne direkt am Servo (habe ich jetzt bei meinem Vinculum zum ersten mal gemacht)

Eventuell ist auch das Signal selbst schlecht, d.h. die Servosignale kommen nicht oft bzw. schnell genug. Hier nochmal das Programm prüfen. Ein Oszi wäre hier natürlich sehr hilfreich. Vielleicht kannst du dir ja irgendwo eines ausleihen oder den Roboter dort hin bringen wo eines ist.

Hallo,

ich danke euch Beiden.

Ja Termindruck ist es ein wenig denke ich - ich möchte doch auch was tolles mitbringen ;)

Allerdings möchte ich nicht übermütig werden und grobe Fehler machen die mir eventuell die SD-21 kosten könnten oder so. Einmal einen Kurzschluss habe ich schon von paar Wochen fabriziert, zum Glück ist nichts weiter passiert außer die + Leiterbahn für die Servos an der SD-21 durchgebrannt ;)

Deswegen habe ich am letzten langen WE die Zeit genutzt und die Elektronik gefühlte 20x auf und ab gebaut um mich an den momentanen Zustand heranzutasten. Das da blos nichts bei drauf geht ](*,)(<--- *auf Holz klopf*)
...sogar den Akku hab ich zwischendurch mal durchgemessen, nicht das der leer gesaugt wird. Die Überwachung dafür hab ich nämlich noch nicht fertig.

Logikspannung kommt momentan von der RN-Control, Leistungsspannung ist der LiPo 7,4V (2S1P)
Den 100Ω Widerstand werde ich sicher ausprobieren. Kondensatoren selbstverständlich auch - allerdings fange ich erstmal etwas kleiner an oder kombiniere eine dreier Gruppe.

Ferritkerne habe ich leider grade nicht da ...und irgend jemand hatte doch letztens ein Oszi rumstehen :-k

Ich versuche noch das Programm mal ohne die ganzen Printausgaben zu fahren. Vielleicht sind 20ms Refreshrate der SD-21 doch schon zu schnell... - da verlässt mich aber meine Fantasie.

Ich danke Dir, Hanno, für die vielen hilfreichen Tipps.

Ich habe übrigens irgendwann die letzten Nächte das Kopfdesign skizziert...und erste einfache Machbarkeitsversuche gemacht.
Mal schauen in wie fern sich das wirklich durchführen lässt.

*mist, ich wollte doch heute Tischtennisbälle kaufen*

Seeeehr schick HeXPloreR !
Ein Hameg 204 stand letztens bei mir herum und steht zu Deiner Verfügung ;-)
Kondensatoren auch !

Vielen Dank Slowly,

Du weißt ja, ich bin wie nen Elefant oder wie Pilz: Ich geh nie wieder weg! <---irgendwas stimmt hier nicht ;)


>EDIT: danke schön...<

IKU freut sich schon Dich mal wieder zu besuchen...hat sie gesagt.

Hallo Freunde,

IKU hat jetzt eine neue Bewegung (klick hier - 3:25min) drauf. Auch das Servo zucken ist weitestgehend verschwunden. Wie das? - ein neuer Servo hat sehr viel Besserung gebracht.
Ein 100Ω Widerstand hat keine merkliche Verbesserung gebracht, Kondenstoren habe ich nur kleine Kerkos ausprobiert - mit mässigem Erfolg.
Die Leiterbahnen der Servospannung habe ich auf der Rückseite auf der SD-21 verstärk - ich bin immer noch der Meinung das die Spannung bei einem LiPo nicht so schnell einbrechen sollte.
Die Logikspannung von der RN-Control wurde mit Kerkos etwas stabilisiert. Da ich hier vermute das der angeschlossen Empfänger der Funkfernsteuerung und die SD-21 Logik doch etwas die 5V Spannung zum wackeln bringt.

Kleine Wackler habe ich immer noch drin, die sind allerdings meistens nur vorhanden weil von der Fernsteuerung ein "kippendes" Signal kommt - also die Hebelstellung leicht wackelt und das Programm das verrechnet. Ist die Steuerung aus, ist auch kaum noch wackeln vorhanden.

Auch sind ist die Servogeschwindigkeit der inneren Servos langsamer, die mittleren sind etwas schneller, die Äusseren sind noch schneller ;)

Die seitwärst Bewegung habe ich noch nicht einprogrammiert. Ich überlege auch noch wo ich im Programm am bessten ansetze.
Momentan ist es ja so das alle Servos die Werte "aus einem Durchlauf" der inversen Kinematik bekommen. Es ist alles noch etwas einfach gehalten.
Das wird sich wohl demnächst auch sehr verändern.

Fragen? Ideen? Tipps und Tricks? Kritik?

Hallo HexPloreR, dass die kleinen Kerkos nichts bringen ist logisch. Sieh dir mal die Ströme an die da fließen, da puffert so ein 100nF überhaupt nichts, selbst ein 1µF reicht da nicht. Bei mir sind aktuell 6x 6800µF!!! verbaut. Nur so habe ich eine realisitische Chance die Spannungspitzen wegzubügeln. Zusätzlich hat jedes Bein nochmal einen 100µF Kondensator.

Könnte allerdings eher ein anderes Problem sein, wenn man sich die Bewegungen so ansieht.

Zitat:

---

Zitat von HannoHupmann

Hallo HexPloreR, dass die kleinen Kerkos nichts bringen ist logisch. Sieh dir mal die Ströme an die da fließen, da puffert so ein 100nF überhaupt nichts, selbst ein 1µF reicht da nicht. Bei mir sind aktuell 6x 6800µF!!! verbaut. Nur so habe ich eine realisitische Chance die Spannungspitzen wegzubügeln. Zusätzlich hat jedes Bein nochmal einen 100µF Kondensator.

---

Ja, der LiPo sollte aber in der Lage sein die Spannung und auch ganz besonders den Strom zur Verfügung zu stellen. Ich bin noch nicht davon überzeugt dass diese 6000µF (!!) Kondensatoren nötig sind. Mein Wissen und meine Ausrüstung reicht hier allerdings auch nicht aus um das abschliessend zu beurteilen.

Zitat:

---

Könnte allerdings eher ein anderes Problem sein, wenn man sich die Bewegungen so ansieht.

---

Was meinst Du? - dieses ruckartigen Bewegungen nach oben... könnte höchstens noch von meiner Fernsteuerung kommen. Ich habe den empfangenen Wert für die Höhe x 2 genommen, damit die Bewegung höher geht. Und die Art wie stückweise z.B. die Beine runterfahren, oder ruckartig runterfahren vdes Körpers - das kommt daher das ich nebenbei auch die Kamera festhalte ;) Kann man verstehen, oder?

Allerdings habe ich für das aktuelle Video auch den automatischen Wackelfilter von YouTube angewendet - jetzt wird man von dem Video allerdings erstrecht seekrank - also das geht garnicht.

EDIT: Ist jetzt wieder das original verwackelte Video, allerdings ohne diesen Welleneffekt vom stabilisieren ;)

Es gibt zwei Gründe für - nennen wir es mal - wackelnde Servos.

1) Die Spannungsversorgung reicht nicht aus und die Servos brechen ein wenn sie belastet werden, da du aber keine Last auf deine Beine hast, sie schweben in der Luft, wird es daran wohl weniger liegen

2) Das Steuersignal ist nicht sauber, ich denke es liegt eher daran, was folgende Gründe haben kann
a) Die Signale werden sauber erzeugt, aber kommen verrauscht beim Servo an. Klassischer Fall wenn Leistungsversorgung und Signalleitungen zusammen verlegt werden. Hier helfen eben Dinge wie 100Ohm Widerstand, Ferritkerne (wie in jedem Computerkabel) und trennen von Signal und Versogungsleitungen.
b) Die Signale werden nicht sauber erzeugt. Entweder generiert dein µC keine sauberen Signale: falscher Pegel (z.B. 3,3V statt 5V), falsches Timing etc. oder die Periodenzeit ist falsch und statt alle 20ms kommt es z.B. kommt erst alle 21ms ein Signal, dann verschiebt es sich immer um 1ms und kann dazu führen, dass der Servo ein paar mal ein falsches Signal bekommt.
c) Die Servos sind nicht in der Lage aus dem Singal eine saubere Winkeländerung zu generieren, dann liegt es wohl an zu billigen Servos
d) Die Kombination aus a, b, und c.



PS: GND von den Servos und der Logik ist aber schon verbunden?

Zitat:

---

Zitat von HannoHupmann

...
2) Das Steuersignal ist nicht sauber, ich denke es liegt eher daran, was folgende Gründe haben kann
a) Die Signale werden sauber erzeugt, aber kommen verrauscht beim Servo an. Klassischer Fall wenn Leistungsversorgung und Signalleitungen zusammen verlegt werden. Hier helfen eben Dinge wie 100Ohm Widerstand, Ferritkerne (wie in jedem Computerkabel) und trennen von Signal und Versogungsleitungen.

---

- Wie trennt man das beispielsweise bei einem RS-2, wo ab servostecker die Kabel nebeneinander bis zum Servo laufen? Bei den Hitecs sind die Kabel ja verdrillt, man könnte die verdrillung also offnen. Wohin kommt dann der Ferritkern?

Zitat:

---

b) Die Signale werden nicht sauber erzeugt. Entweder generiert dein µC keine sauberen Signale: falscher Pegel (z.B. 3,3V statt 5V), falsches Timing etc. oder die Periodenzeit ist falsch und statt alle 20ms kommt es z.B. kommt erst alle 21ms ein Signal, dann verschiebt es sich immer um 1ms und kann dazu führen, dass der Servo ein paar mal ein falsches Signal bekommt.

---

- SD-21 gibt die Signale alle 20ms aus. Ich stelle jetzt mal in den Raum dass das dann auch so ist. Aber warum sollte das Signal denn bei z.B.21ms falsch sein - es ist doch dann immer noch 1500µs +- lang? Nur verliert er dann seine Position in der zwischenzeit, weil er mehr Zeit hat abzufallen, eben eher. Zur Erinnerung: es sind Analoge in der Hüfte und "der digitale Rest". Schneller befeuern kann man sie auf jeden Fall.

Zitat:

---

c) Die Servos sind nicht in der Lage aus dem Singal eine saubere Winkeländerung zu generieren, dann liegt es wohl an zu billigen Servos

---

...das denke ich nicht.

Zitat:

---

d) Die Kombination aus a, b, und c.

---

- Die Signalqualität gilt es anscheinen mal zu prüfen.

Zitat:

---

PS: GND von den Servos und der Logik ist aber schon verbunden?

---

...aber na klar ...man bin ich froh, das Du nichts mehr von Kondensatoren gesagt hast ;)

Ich denke, das es jetzt ja schon sehr viel besser und ruckelfreier läuft nachdem ich den besagten analogen Servo ausgetauscht habe. Ich vermute durch diese Störungen die der verursacht aht wurden die jeweils nächsten auf der SD21 gesteckten Servo mitbeeinflußt. Das kann ich ja nochmal gegenchecken - rein optisch und taktil versteht sich ;)

Nur nochmal kurz zum empfang der Werte:

Die Fernsteuerung gibt Werte von ca 90 Einheiten pro Knüppel aus, es ist eigentlich egal um welchen Mittelwert der kreist - denn diese rechne ich im Programm auf -45 bis +45 um. Das ist dann der Wert der direkt in die IK einfließt und momentan bewirkt das alle Beine das gleiche tun.
Ich beeinflusse auch nur den Y-Wert und den Z-Wert für die Beine ab der Hüfte. Jedoch in einer, im Vergleich zum Servo sehr schlechten Auflösung: Servo=1400µs (sind 140°); RC-Funk=90 (ergibt 90°), da ich vorerst auch nur einen Bereich von 900µs (90°) im Servo brauche, passt der Bereich der Funke recht gut - nur ist der eben 10x geringer.

Ich sehe die Auflösung des Eingangssignals auch als Problem. Ich arbeite auch an einer Lösung. Diese soll die Veränderung am Knüppel im Programm (bzw sonstigen empfangenen Werte zur Verarbeitung) hochzählen. Allerdings hat es keine hohe Priorität bei mir, da es an sich ja funktioniert.

Das ist ein Fall für ein Oszi Hexplorer.
Die zweite Lage Kekse ist noch hier :)
Viele Grüße
Slow

Ey, Du sollst die doch aufessen :p - die Dose rostet doch...

Wie immer gilt, der Fehler steckt im Detail und dummerweise haben diese Hexas mindestens 18 Details. Die Frage nach dem verbundenen GND stell ich nur um sicher zu gehen, dass sowas triviales nicht übersehen wird. Selbst mir passiert es manchmal noch, dass ich bei all meinen hübschen Verdrahtungen irgendwas rudimentäres vergesse.

Die Ferritkerne kommen so nah es geht an die Servos dran. Kuckst du hier:
Bild hier  
Ganz rechts am Hüftservo sieht man den Ferritkern

Spielen wir das mal mit 21ms durch, dann kommt raus, dass sich bei jeder Signalvorgabe, das Signal selbst um 1ms verschiebt. Damit wandert der High-Impuls kontinuierlich durch den Signalbereich von 20ms, was erst mal kein Problem ist. Allerdings wird er irgendwann hinaus geschoben und dann wirds spannend, denn nun wird das Signal ein paar mal "zerschnitten" bis es wieder - durch die Verschiebung - im Signalbereich liegt.

Mal eben grafisch gezeigt
..........||||||.. Signal i.O
...........||||||. Signal i.O
............|||||| Signal i.O
.............||||| Signal n.i.O da zu kurz (nur 5 high)
|.............|||| Signal n.i.O da zu kurz
usw. bis das Signal wieder so aussieht:
||||||........... Signal i.O

Digitale in der Hüfte? Prüf mal bitte ob das SD21 überhaupt mit Digitalen so ohne Umstellen klar kommt, soweit ich mich erinnere und ich hatte das Board auch mal, ist es für analoge Servos ausgelegt. Könnte sein, dass du hier ein Problem hast.

Alles nur Ideen sicher kann ich es auch nicht sagen, aber ein Blick mit dem Oszi auf die Signale würde da schon weiter helfen. Klassisch prüft man erst mal ob saubere Signale aus dem µC kommen, dann aus dem SD21 und am Ende ob die auch am Servo noch so aussehen.
Danach kann man sich die Versorgungsspannung anschauen und wird hoffentlich den Fehler finden.

Zitat:

---

Prüf mal bitte ob das SD21 überhaupt mit Digitalen so ohne Umstellen klar kommt, soweit ich mich erinnere und ich hatte das Board auch mal, ist es für analoge Servos ausgelegt. Könnte sein, dass du hier ein Problem hast.

---

Warum denn nicht? Das Signal zur Servoansteuerung ist doch nur ein popeliges PWM Signal. Ich glaube man kann ausschließen dass das ein Problem ist.

Danke Hanno, für die Erklärung.

Also so direkt finde ich nichts wo steht das digitale nicht funktionieren sollen. Lynxmotion Forum habe ich schön öfter quer gelesen, dort gehst aber eher um das SSC-32. Und selbst da sagt keiner was dazu das jemand da Analoge und Digitale an einer Card benutzt. Ebenso im Arduino Forum. Ich verweise hier mal auf SENSOBOT 3
Allerdings hat er ja auch ausschliesslich digitale Servos an der SD21 - und nicht auch zusätzlich Analoge.
Auch ein Kollege meinte schon: "Kann man nicht mischen" - kann man nicht? warum nicht? Was interessiert den analogen Servo ob nebenan ein Digitaler dran ist?

EDIT: Habe jetzt die ganze Zeit die Links hier rein gezogen, und gesucht...da habe ich malthy's Beitrag überhaupt nicht mitbekommen.

Obwohl ich mit Servos wenig zu tun hab, gebe ich mal meinen Senf dazu da ich schon so manche elektronische Schaltung debugged habe.

Das A und O zum funktionieren einer Elektronik ist die Versorgung. Wenn die nicht steht, und damit meine ich nicht ein "wenig" Brumm oder Ripple, sondern daß sie immer innerhalb des für die Elektronik spezifierten Bereich ist, braucht man sich den Rest garnicht erst ansehen.

Ohne jetzt die Schaltung zu kennen, wobei die Innenschaltung eines Servos selten bekannt ist, halte ich Spannungseinbrüche von mehr als 5% für bedenklich. Wenn sie sehr kurz sind, sind sie noch problematischer, da man sie mit typischen Messmitteln schlecht erfasst und sie in Wirklichkeit eher größer sind. Analoge Schaltungen sind da toleranter, digitale fangen sich einen extra Clocksignal ein und µCs spielen verrückt oder gehen über Los.

Leider ist das "Konzept Servo" von Beginn an vermurkst. Sowohl die Leistung, der Motor, als auch die Elektronik werden aus der selben Quelle versorgt. Als dieses Konzept entstand, war das aber verständlich. Die Servos haben ein paar Ruder und das Gas vom Verbrenner gedreht, und das war zusammen mit dem Empfänger die ganze Elektronik in einem Modell. Die gemeinsame Versorgung hat sich aber bis heute erhalten, obwohl die Servos nicht mehr ein Seitenruder drehen sondern das Modell bewegen. Man muß also damit leben, oder wie bei Dynamixel die Versorgung des Motors von der Ansteuerung trennen (was einen nur noch begrenzt kompatibel zu bestehenden Systemen macht).

Kurz und gut, am Servoanschlußstecker muß die Spannung immer im für die Servos angegebenen Bereich sein. Und damit die Steuersignale ein definiertes Potential haben, muß insbesondere GND stabil sein. Vom Controller bis zum Servo sollten da nicht mehr als wenige zehntel Volt zu messen sein (dynamisch mit dem Scope).

Und etwas zu den Steuersignalen. Wenn diese gestört sind, helfen Ferrite genausogut wie Handauflegen. Sie verhindern das Aussenden von HF (zweistellige MHz) und haben auf Servosignale (zweistellige Hz) keinen Einfluß. Wenn also Funk oder Radio gestört wird, können sie helfen.

Längswiderstände sind ebenso kontraproduktiv. Sie verkleinern das Signal und vermindern daher den Störabstand. Wenn das Servo Signale mit TTL Pegeln akzeptiert (und so haben die Servos angefangen), ist der Störabstand bei Low besonders kritisch. Ein gültiges Low am Eingang ist da kleiner als 0,8V. Verliere ich da am Längswiderstand einige Zehntel Volt, habe ich meinen Störabstand schon fast verbraucht.

Übersprechen zwischen Servoversorgung und Steuerleitung ist ein anderes Ding. Da der Hersteller seine Teile getestet hat, sollte das funktionieren. Verlängere ich das Kabel, könnte es zum Problem werden. Es lässt sich aber leicht Messen und durch Austausch des Kabels ebenso leicht vermeiden.

Die 20ms des Servosignals sind gar kein Problem. Interessant ist nur die Pulslänge. Der Unterschied zwischen Analog und Digitalservo lieg darin, daß das analoge Servo den Motor nur ansteuert, wenn ein Puls kommt. Kommt er zu selten verliert es die Position, kommt er zu häufig, können sich die eingesetzten Monoflops nicht richtig entladen. Viele Fernsteuerungen liefern keine konstanten 20ms, sondern, wenn alle Kanäle auf Vollausschlag sind, ein längeres, sonst ein kürzeres Signal. Für ein analoges Servo beginnt bei jedem Puls ein neuer Zyklus, von 20ms weiß das nichts.

Ein Digitalservo misst nur die Pulslänge. Die Steuerung des Motors ist davon unabhängig. Und was es tut, wenn das Signal mal (viel) später kommt, hängt vom Modell ab. Bessere Modelle haben an der Stelle eine Fail Safe Automatik. Sie können auch den Einstellwert statt als Pulsbreite, via UART, RS485 oder I²C bekommen (Dynamixel).

Das wichtigste ist, Messen! Und zwar dynamisch, mit einem Scope. Da die Servosignale langsam sind, so 50Hz, und sich ständig wiederholen, kann man auch ohne Tricks selbst mit einem einfachen, analogen Scope etwas erreichen.

Unabhängig davon, die Stromsersorgung ist das A und O. Von der Versorgung bis zu Servoverteiler fließen kräftige Ströme (z.B.): 18 Servos a' 2A ==> 36 A, 0,1 Ohm Kabel und Übergangswiderstand ==> 3,6V. Soetwas kann man auch nicht mit µF kitten, nur mit massivem Kupfer. Da helfen die Car HiFi Leute, überall gibts 2,5² oder 4² Kabel für kleines Geld.

Viel Erfolg

Klebwax

Zitat:

---

Zitat von Klebwax

...
Unabhängig davon, die Stromsersorgung ist das A und O. Von der Versorgung bis zu Servoverteiler fließen kräftige Ströme (z.B.): 18 Servos a' 2A ==> 36 A, 0,1 Ohm Kabel und Übergangswiderstand ==> 3,6V. Soetwas kann man auch nicht mit µF kitten, nur mit massivem Kupfer. Da helfen die Car HiFi Leute, überall gibts 2,5² oder 4² Kabel für kleines Geld.

---

Genau das war bei meinem Vinculum das Problem, denn 18 Servos ziehen hier zwar keine 36A, aber zumindest gut und gerne 7,5A... 12A, da war a) mein Labornetzteil zu schwach auf der Brust und b) zu träge, da es sich um Stromimpulse handelt. Auch der Akku in Kombination mit SBEC konnte diese Spitzen nicht abdecken, die bei der Initialisierung entstehen. Abhilfe war dann eben eine wirklich dicke Kondensator-Bank die auch genug Leistung liefert. Zudem dicke Kabel die den Strom an die Beine verteilen, erst dort geht es dann mit den dünneren Servoleitungen weiter.

Ob sich nun die Ferritkerne und die 100Ohm Widerstände positiv auswirken oder nicht, möchte ich gar nicht groß diskutieren, ich habe sie einfach eingebaut. Zumal mein µC im 80Mhz bereich arbeitet und ich da keine Störsignale haben will.

Hinzu kommt die Versorgung von Servos und Logik aus zwei unterschiedlichen Quellen. Einmal ein 7,2V LiPo und ein 9V Block Akku, letzterer ist nur für Logik, Sensoren und Co gedacht, keine Leistungselektronik. Gerade letzteres hilft enorm, das zeigt die Erfahrung.

Das die Hersteller ihren billigen No-Name Servos testen, wage ich allerdings zu bezweifeln. Bei den Markenservos für viel Geld wird es sicher so sein, aber bei 10€ China-Zeugs ist kein Geld für Tests vorhanden!