Hexapod - "IKU"

[HeXPloreR]

Hallo Community,

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

Ich orientierte mich dabei an Matt Denton's "i.c. - Hexapod" (http://www.youtube.com/watch?v=4oXuSXCKJeY).
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 (http://www.servocity.com/html/hs-5645mg_digital_torque.html) 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 (http://www.mtahlers.de/index.php/robotik/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):

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 ;)

[HannoHupmann]

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.

[HeXPloreR]

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.

[rolber]

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

[HeXPloreR]

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 ;)

[oberallgeier]

Hallo HeXPloreR,

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


... 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?

[HeXPloreR]

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:

[HeXPloreR]

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*

[HeXPloreR]

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.

[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.

[malthy]

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

[HeXPloreR]

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.

[malthy]

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 ... :-)

[HeXPloreR]

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 ;)

[HeXPloreR]

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:
2552725528255292553025531

[Geistesblitz]

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?

[HeXPloreR]

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:25532 und hier von unten, sieht man den Bund besser:25533
Die ganze Befestigung des Teils war anders gedacht, die habe ich aber verworfen.

[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.

[HeXPloreR]

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.

[HeXPloreR]

Hier mein Testvideo: IKU - erste Bewegungen mit inverser Kinematik (1:49) (http://www.youtube.com/watch?v=QdTE2hw1zPA)

[Geistesblitz]

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.

[malthy]

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?

[HeXPloreR]

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 :(

[m.a.r.v.i.n]

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.

[HannoHupmann]

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.

[HeXPloreR]

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*

[Slowly]

Seeeehr schick HeXPloreR (https://www.roboternetz.de/community/members/35937-HeXPloreR) !
Ein Hameg 204 stand letztens bei mir herum und steht zu Deiner Verfügung ;-)
Kondensatoren auch !

[HeXPloreR]

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.

[HeXPloreR]

Hallo Freunde,

IKU hat jetzt eine neue Bewegung (klick hier - 3:25min) (http://www.youtube.com/watch?v=RvxNyNZ4aUg) 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?

[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.

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

[HeXPloreR]

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.



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 ;)

[HannoHupmann]

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?

[HeXPloreR]

...
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?



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.



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.



d) Die Kombination aus a, b, und c.
- Die Signalqualität gilt es anscheinen mal zu prüfen.



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.

[Slowly]

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

[HeXPloreR]

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

[HannoHupmann]

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:
https://www.roboternetz.de/community/attachment.php?attachmentid=25418&d=1367777615
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.

[malthy]

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.

[HeXPloreR]

Danke Hanno, für die Erklärung.

Also so direkt finde ich nichts wo steht das digitale nicht funktionieren sollen. Lynxmotion Forum (http://www.lynxmotion.net/viewtopic.php?f=2&t=5461) 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 (http://forum.arduino.cc/index.php/topic,18446.0.html). Ich verweise hier mal auf SENSOBOT 3 (http://www.sensobot.de/index.php?option=com_content&view=category&layout=blog&id=3&Itemid=5)
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.

[Klebwax]

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

[HannoHupmann]

...
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!

[HeXPloreR]

Hallo alle zusammen,

so nun ist die Maker Faire Hannover (https://www.roboternetz.de/community/threads/60790-c-t-Hardware-Hacks-veranstaltet-Maker-Faire-Germany-am-3-8-2013-in-Hannover) geschafft. Es war wirklich sehr warm dort, aber es hat unglaublich viel Spaß gemacht die interessierten Leute dort zu sehen. Und mal von einem kleinen Jungen abgesehen, der an einem Roboter "mal eben so" die verschiedenen On/Off Schalter bedienen wollte, hatten, denke ich, alle Respekt vor unseren Projekten.

Die IKU hat sich gut geschlagen. Ich hatte ja bedenken ob das alles gut geht da ... es war aber sogar sehr gut - dafür hat sie sich einen extra Akku verdient.

Der Hexapod hat doch für die eine oder andere Schockreaktion am Stand gesorgt. Ganz besonders wenn die Besucher nicht mit einer Reaktion des Roboters gerechnet haben. Auch wenn die (Körper-) Bewegungen noch nicht ganz sauber aussehen, freue ich mich das ich keine Ausfälle oder ähnliches zu beklagen hatte.
Ich hatte 3 LiPo Akku's (3600/3700/5000mAh) mit wobei ich den zweiten bis zuletzt drin gelassen hatte - der hätte auch noch ca. ne Stunde drinbleiben können. Den Dritten hatte ich überhaupt nicht gebraucht.
Ab und zu hatte ich nur die Servos von der Spannung getrennt, damit sie etwas abkühlen konnten. Wobei der Sensorkopf trotzdem immer noch seine Runden gedreht hat.

Da ich ja immer die Leute die mit IKU "gespielt" haben beobachtet hatte, fiel mir auf das die Sensoranordnung doch etwas ungünstig gewählt ist. Das ändere ich also gleich schon mal ab.

Einige Leute fragten wie man dem Roboter das laufen auf unebenen Gelände beibringen könnte.
Nun, ich habe dazu die beiden Ansätze per Drucksensoren oder per einfachen Taster. Ich tendiere noch zu der einfachen Lösung mit den Tastern.

In dem Zusammenhang habe ich auch mit malty unterhalten...und da ich von Samstag auf Sonntag(heute) so schlecht schlafen konnte...da ist es mir auf gefallen warum malty meinen Standpunkt nicht verstanden hat bzw auch nicht konnte: malty ist nämlich schon mindestens einen Schritt weiter als ich - im wahrsten Sinne. Und er hat natürlich recht mit seinen Argument das die inverse Kinematik nicht den puren Endpunkt anfährt - ganz besonder natürlich nicht wenn ein Schritt getan wird.
Sorry malty, da haben wir aneinander vorbeigeredet, denn ich war noch im Gedanken bei meinen einfachen verschiebe Spielchen mit den Beinen. Ohne das mir "die Schrittkurve" eingefallen ist - die ja selbsverständlich auch durch die inverse Kinematik geschickt, und daher auch per Taster oder sonstige geeignete Sensoren an einer definierten Stelle angehalten werden kann - welche dann die neue Höhe ergeben würde ;)
Allerdings habe ich mit meiner IKU noch keinen einzigen Schritt getan, von Gelände garnicht zu reden...also da muss mein Weg noch hingehen ;)
Sicher haben einige Menschen, denen ich versucht habe zu erklären wie die Beine momentan bewegt werden, bemerkt das ich mir das Ganze noch ziemlich einfach halte.

@ malty, Du siehst hoffentlich auch wenn ich im Gespräch nicht gleich drauf gekommen bin, irgendwann machts auch bei mir klick.... nur wann :cheesy:
Wir haben uns (Sabas und ich) Deinen Humanoiden kurz angesehen, schade das Du da grade nicht an Deinem Stand warst.

Von Strommessung direkt am Servo rate ich allerdings immer noch ab. Das hatte ich bei meinem Bioloid mal versucht, es hat bei mir damals nur mit Einschränkungen funktioniert, und war im Endeffekt dann nicht zufriedenstellend.


Jemand anderes fragte ob man für die Fußsensoren auch einen Sharp Infrarot Sensor nutzen könnte. Hierzu ist mir noch was wichtiges eingefallen - vielleicht liesst er das ja mit: Wenn man einen Sharpsensor benutzt kann es gut sein das man einen "boden" detektiert der nicht tragfähig genug für den Roboter ist. Daher empfehle ich keinen optischen Sensor an dieser Stelle, sondern einen taktielen - der also wirklich körperlichen Kontakt mit dem Boden bemerken kann. Ein Taster, wahrscheinlich mit einer auf Robotergewicht einstellbaren Feder davor könnte ich mir vorstellen. Oder auch ein Poti mit Federeinstellung über ADC's- was allerding etwas aufwendiger erscheint als die Tasterversion über Interrupt. Wenn man jedes Bein einzeln setzt, benötigt man auch keinen Spannungsteiler - da man ja programmseitig das Bein kennt welches sich gerade senkt.
Nur wenn man zwei/drei Beine im gleichen Moment absenkt, würde man um die Höhen zuordnen zu können einen Spannungsteiler auf einem ADC benötigen.

Ich denke mit diesen Ansätzen kann man etwas anfangen.

So und nach diesem riesen Artikel, möchten "wir beide" uns ganz herzlich für das rege Interesse bedanken - sie hat sich auch sehr gefreut euch alle kennen zu lernen.

Ich bereite demnächst auch einige "Flugblätter" vor ... vielleicht auch in Englisch...ich hörte davon, es ist wohl eine Weltsprache ;)

26154261552615626157261582615926160

[radbruch]

Hallo


Nun, ich habe dazu die beiden Ansätze per Drucksensoren oder per einfachen Taster. Ich tendiere noch zu der einfachen Lösung mit den Tastern.

Von Strommessung direkt am Servo rate ich allerdings immer noch ab.

Kennst du meinen Servo-Sensor-Thread? Über einen nicht dokumentierten Effekt an der Signalleitung wird die Belastung des Servos beurteilt. Allerdings wurde das nicht gründlich erforscht, keine Ahnung, ob es auch bei hochwertigen Servos funktioniert:
https://www.roboternetz.de/community/threads/33909-Minimall%C3%B6sung-Servo-Sensor


http://www.youtube.com/watch?v=39tOx0IxQ40

Gruß

mic

[HeXPloreR]

Hallo mic,

danke dafür, nein kannte ich tatsächlich noch nicht wirklich. Aber es sieht vielversprechend aus.

Bei Gelegenheit lese ich mir den Thread durch.

EDIT: Okay, das scheint ja recht gut zu klappen. Wenn man jetzt nur noch verlässliche Daten hätte.

Mein problem ist natürlich das ich vermutlich noch nicht so tief ins programmieren eingearbeitet bin um das umzusetzen und das meine Hardware (SD-21) irgendwie mit dem Messzeitpunkt syncronisiert werden müsste, wenn es damit überhaupt funktioniert - wegen der Umschaltung auf Eingang - da könnte ich mir vorstellen das es die SD-21 stört / sie komplett raus muss.

[malthy]

Hallo HeXPloreR!

Es war schön dich und deinen Roboter mal persönlich zu treffen! Sorry dass ich zwischdurch nicht an meinem Stand war. Habe den Vormittag über wirklich pausenlos geredet und das bei dieser extremem Hitze in der Halle. Das hat mich echt etwas mitgenommen. Im Verlauf des späteren Nachmittags habe ich mir dann hin und wieder mal ein Pause gegönnt, um ein bißchen Ruhe und Erfrischung zu haben - vor allem auch um mir mal Projekte anderer Leute anzugucken ...

Kann gut sein dass wir unterschiedliche Sachen im Kopf hatten als wir uns unterhalten haben :-). Du schreibst "Und er hat natürlich recht mit seinen Argument das die inverse Kinematik nicht den puren Endpunkt anfährt". Das ist natürlich etwas mißverständlich, bin mir nicht mehr ganz sicher was genau der Zusammenhang ist den du meinst. Die IK sagt ja einfach nur die Gelenkstellungen, die man braucht, damit der Fuß einen bestimmten Punkt einnimmt. Alles andere wäre falsch und wollte ich nicht zum Ausdruck bringen. Was ich da gestern auf der Faire nur meinte ist: weil der Servo ein geregeltes System ist, kann man sich (unter einigen Randbedingungen natürlich) "sicher" sein, dass, wenn man dem Servo über das PWM Signal sagt "nehme Winkel w" ein, er diesen Winkel auch tatsächlich einnimmt und hält. Man braucht deswegen i. d. R. selber kein Positionssignal, man geht einfach davon aus, dass der Servo da ist, wo man ihm befohlen hat zu sein. Das war eigentlich schon alles was ich in dem Moment sagen wollte :-).

Viele Grüße
Malte

[HeXPloreR]

Hallo Malte,

es hat mich auch gefreut "euch" mal in Real-3D und in Farbe zu treffen.

Na das mit dem Endpunkt hatte ich ja die ganze Zeit so gesagt, aber die Berechnungen für die "jederzeit aktuellen" Winkel dazwischen - ist mir irgendwie entgangen in dem Gespräch - das man sie ja zu dem Zeitpunkt der Bodenkontaktes kennt, man müsste sie dementsprechen also nur noch selektieren und als neuen Höhenwert fixieren, damit dann der Schritt beendet ist.

Ich denke in etwa so hattest Du Dir das gedacht - nur mein aktives Vacuum hat das nicht gerafft in dem Moment.
Well, das wollte ich nur nicht so zwischen uns stehen lassen...sonst schlafe ich immer so schlecht ;)

Der Tag war wirklich anstrengend, ich merk das heute auch. Für mich sind so viele Leute eher streßig, dabei ist es nicht mal die Menge sondern die Nebengeräusche die dann so ein Raum entwickelt, da komm ich mit meiner Kratzstimme nicht gegen an - aber dennoch hat es riesen Spaß gemacht irgendwie :)

[Andree-HB]

...wir sollten das nächste Mal mal ein Erkennungszeichen ausmachen - dann weiss man auch mal im Gewusel, dass man den Gegenüber ja auch durchaus "kennen" könnte. Den Oberallgeier habe ich z.B. am Stand von Malte zufällig kennengelernt.

- Vielleicht eine Ventilatorblume ins Knopfloch oder so - :-)

[HeXPloreR]

...aber die Idee ist gut. Ich wäre dafür das wir sone Pins zum anstecken mit mindestens Community und dem Nickname versehen ;)

Andree, eure T-Shirts die waren ja schon sehr gut auffällig. Hattest Du mir nun eigentlich den Tischtennisball vorbeigebracht? - ich muss gestehen, es war mir ein µ zu laut dort, ich habe Deinen Namen nicht richtig verstanden, nur interpoliert ;)

[Andree-HB]

jipp...Andree aus der Hansestadt Bremen hatte Dir einen "Jörg" vorbeigebracht, allerdings ohne Schnörkel...weil das Drucken der Dinger der Lütte vom Vereinskollegen übernommen hat....und der war gegen Ende so unglaublich platt, der ist mir noch im Parkhaus auf der Rücksitzbank eingepennt. :-)
http://www.haz.de/Hannover/Fotostrecken-Hannover/Die-Maker-Faire-im-HCC#p14

[oberallgeier]

... wir sollten das nächste Mal mal ein Erkennungszeichen ausmachen ...
... das wir sone Pins zum anstecken mit mindestens Community und dem Nickname ...Ja, und ja. Ich hatte mir ein Schildchen, passend zu meiner Umhänge-Eintrittskarte ausgedruckt, große, dicke, deutliche Schrift - und recht früh das Halsband abgelegt; es war einfach ALLES zu heiß. Ich glaub ne Nadel mit aufgeklebtem RN-Logo (dazu Nick, evtl. "RN" - zur Erinnerung) im 20mmx20mm-Briefmarkenformat wäre praktisch. Evtl. für Sommertage auf Luftpostpapier *gg*.


... weil der Servo ein geregeltes System ist, kann man sich (unter einigen Randbedingungen natürlich) "sicher" sein...Na ja, vielleicht bei teureren Servos. Aber auch dafür würde ich die Hand nicht ins Feuer legen. Über diese Pleite beim RS-2 hatte ich ja schon berichtet, (https://www.roboternetz.de/community/threads/61379-Kopfsache-und-ein-m1284-etliche-Servos-viel-Alu?p=579801&viewfull=1#post579801) der größengleiche HK-Typ von pololu (https://www.roboternetz.de/community/threads/61379-Kopfsache-und-ein-m1284-etliche-Servos-viel-Alu?p=583165&viewfull=1#post583165) hat da sehr viel weniger Abweichung, erstmal kaum merkbar; wieviel konnte ich bisher aus Zeitmangel nicht er-messen. Aber das kommt - mit Bericht. Bei diesem Messaufbau will ich auch gleich mic´s Perioden-Pausen-Sensorik (mic - danke für die Erinnerung und den Link) aufbauen und testen.

[HeXPloreR]

Moin Moin,

ich wollte nur mal einen kurzen Zwischenstand abgeben:

Das Bascom Programm ist nun soweit umgeschrieben das jedes Bein seinen eigenen nächsten anzufahrenden Punkt bekommt.
Vorher hatte ich es ja sinngemäss eher so gelöst dass alle Beine das gleiche tun - sie standen also parallel und hatten dementsprechend auch die gleichen Winkel zurückzulegen um den Körper zu bewegen. Die Beine hatten auch noch keinen rechnerrischen Bezug zum Körper - auch das ist jetzt integriert, alle Berechnungen gehen vom "Centrum" (x=0; y=0, z=0) des Körpers aus. Und die IK berechnet, nachdem der Körper weggerechnet wurde, die einzelnen Werte für die Winkel.
Das herausrechnen des Körpers sollte insofern zum tragen kommen, wenn man den Körper kippen möchte, da sich hier die Winkel und Längen der Projektion des Körpers zum Boden ändern. Es wird hier also (hoffentlich) schon ein Grundstein mitgelegt, den man aber nicht nutzen muss.
Das Programm umfasst jetzt knapp 750 Zeilen Code - wobei man durch meinen vielen Kommis und Trennzeilen, bestimmt ca. 150 abzeiehn kann.
Das ergibt eine Datei die ca. 30 % der 32kB Flashspeicher benutzt.

Konkret bin ich jetzt dabei die Verschiebung des Körpers neu zu programmieren und auch meinen "ersten echten Schritt" zu erreichen.
Das soll auch einige Grundsteine für kurvengehen und dergleichen legen.

Leider sind doch einige Toleranzen in meinem Aufbau. Diese sorgen nun dafür das sich die Hüftservos nicht ganz sauber in einer Ebene drehen, und dadurch die Höhe etwas verreisst.
Das wird so bald wie möglich korrigiert.

[HeXPloreR]

Hallo allerseits,

ist es wirklich schon wieder ein ganzes Jahr her seit ich hier zuletzt was geschrieben habe :-k

Nun, was gibt es neues ... ich habe nun die Möglichkeit den Körper zur den Seiten und nach vorne/hinten kippen zu lassen.
Nur irgendwie hat sich hier ein (Denk-/Rechen-)Fehler eingeschlichen, anscheinend ist es mir bisher nicht möglich den Roboterkörper korrekt um einen virtuellen Punkt im Roboterkörper kreisen zu lassen.
Es funktioniert mit den äußeren Beinen - also beide Vorderen und beide Hinteren - wunderbar.
Aber mit den mittleren Beinen scheint es so zu sein als wenn die Beine nun schieben - also den Körper wegdrücken. Das soll so nicht passieren.

Ich habe nach meiner Skizze bei einer Verkippung nach vorne einen Winkelversatz berechnet. Nach der Skizze müsste sich dabei der Hüftwinkel der mittleren Beine ja geringfügig ändern da sich der Winkel der Beinhöhe auch entsprechend der Verkippung ändert. Die Nachführung dieses Servos bewirkt nun das schieben.
Ziel sollte es sein das beim Verkippen alle Fußpunkte am gleichen Ort bleiben und nur um ein virtuellen Drehpunkt im Roboterkörper gedreht wird. Dieser Punkt sollte auch fix sein. Das Ziel wird hier dementsprechend nicht erreicht bzw ich bin mit dem bisherigen nicht zufrieden.
Irgedwo hab ich noch einen Fehler in der Berechnung und komme nicht so recht drauf. Da die Verkippung mit den mittleren Beinen etwas anders berechnet ist, im Vergleich zu den vorder und hinteren Beinen, vermute ich hier natürlich mein Problem.

Ist meine Rechenansatz vielleicht grundlegend falsch und ich sollte von den Fußpunkten aus rechnen und den Virtuelle Punkt womöglich auch auf den Untergrund legen?
Momentan berechne ich aus der Mitte des Koordinatensystems (der fixe virtuelle Punkt im Roboter) wo die Fußpunkte wären wenn es gekippt wird.

Vermutlich liegt es an dem Schwerpunkt des Hexas, der ja nun mal irgendwo mittig liegt, deshalb fällt der Körper bei den vorder und hinter Beinen korrekt ab, aber drückt natürlich auf die Mitte und damit auch auf die Beine, die dann diese Verhalten produzieren.
Da es zwei Beine betrifft ist es für mich keine Alternative einen Schritt mit den betreffenden Beinen auszuführen.

Ich versuche demnächst mal die Berechnung umzuschreiben, so das der Abstand der Fusspunkte gleich bleiben muss und daraus dann die korrekten Beinwerte errechnet werden müssen. Ich denke da irgendwo wird der Fehler sein, denn ich ändere ja diesen Abstand - was wohl falsch ist. Logisch: Ändert sich dadurch ja der jeweilige Fußpunkt.

Wer hat eine Idee dazu?

Viele Grüße
Jörg

[HannoHupmann]

Bei meinem Vinculum habe ich verschiedene Ebenen der IK implementiert um über die komplexe Berechnung die Übersicht zu bewahren. Die beiden Kipp-Bewegungen um die x- und y-Achse (oder Längsachse, Querachse) sind im Prinzip durch die variable Höhe des Körpers zum Boden bzw. eben Abstand Schulter - Boden pro Bein definiert f(L, Q) = h(1..6). Ist die Höhe h für alle Beine gleich, dann steht der Roboter gerade auf dem Boden. Der Abstand der Fussspitze zum Schultergelenk wird automatisch berechnet, denn dieser ist eine Funktion der Höhe.

Der langen Rede kurzer Sinn: ich habe eine Ebene 0, bei der aus der Vorgabe: X,Y Koordinate der Fusspitze + Höhe, die Gelenkwinkel für die Servos hervor gehen.
In der Ebene 1 wird aus der Neigung L und Q das delta h für alle Beine berechnet. f(L,Q) = dh(1...6) + h(1...6). Später wird ein Neigungssensor erkennen wie "schräg" der Roboter steht und daraus eine Ausgleichsneigung bestimmen die er an die Ebene 1 übergibt.

Dabei ist es mir allerdings egal ob der Drehpunkt im Zentrum des Roboters liegt oder außerhalb, denn der Winkel für L und Q bleibt gleich.


Kleiner Nachtrag noch:
Die Koordinaten des Fusspunkts sind natürlich davon abhängig was maximal bei h + dh rauskommen kann. D.h. für Punkte sehr nahe am Körper ist viel h + dh möglich für Punkte sehr weit weg vom Körper nicht.

[HeXPloreR]

Vielen Dank HannoHupmann,

ich denke im Prinzip habe ich das auch schon so.... ich rechne auch die winkelabhängige Längenänderungen der X-Y-Achsen beim kippen in die IK mit ein und passe die Z-(Höhen-)Achse dementsprechen an. Wenn wenigstens meine Programmierung nicht falsch ist - von dem angesprochen Problem mal abgesehen - dann funktioniert es so. Allerdings stellt sich eben dieses Problem ein. Ich muss es wohl nochmal ganz langsam und genauestens prüfen und testen.

Eine Frage: Du berechnest also wirklich alle Beine gleich, oder weicht es auch mal irgendwo ab um etwa (mögliche auftretende) Sonderfälle abzufangen? ich frage das deshalb weil ich ja der Meinung bin ein Mittelbein wäre ein Sonderfall bzw anders zu rechnen als vorne und hinten.

Also nochmal das Problem in kurz: senke ich den Vorderkörper ab, steigt im gegensatz dazu der Hinterkörper auf - um den Nullpunkt drehend. Würde man jetzt die mittleren Bein in der Hüfte nicht nachführen würden sich die Fußspitze vom Boden entfernen und mit dem Verkippungswinkel nach hinten zeigen.
Es entsteht als ein kleines Dreieck, welches ich schon mit einrechne um die Änderung der beiden Fußpunkte abzufangen. Doch dabei entsteht das angesprochen Problem der nicht erwünschte leichte Bewegung des Roboters in die Gegenrichtung.

Hat jemand diese Problem auch schon gehabt und kann einen Tipp geben, woran es vemutlich liegt ...

Viele Grüße
Jörg

[rolber]

Hallo HexPloreR !!!

Ist denn wirklich schon wieder ein Jahr um?

Habe deine Ausführungen mit Interesse gelesen.
Kann mich noch schwach an die Anfänge beim Sensobot3 erinnern.
Der ist ja vom grundsätzlichen Aufbau deinem IKU sehr ähnlich.
Habe mir dann die erste Bewegungen mal angesehen:
http://youtu.be/43qlUMm7iYs
und die Programmierung angeschaut.
Wenn ich den Bot um die X Achse habe "kippen" lassen, wobei die x-Achse genau durch den Mitte der beide mittleren Beine geht, dann:
Bewegen sich die vorderen und hinteren Beine exakt umgekehrt mit den gleichen Werten.(Vorne Bot hoch , hinten Bot runter) und die mitteren Beine stehen auf der Stelle.
Wenn der Bot seitlich kippt, also Drehung um die Z-Achse, dann bewegen sich alle Beine auf der linken Seite nach Oben (Beispiel für eine Richtung) alle mit den gleichen Werten und auf der rechten Seite nach unten mit den umgekehrten Werten.

Also:
Je nachdem um welche Achse sich dein Bot dreht, ändert sich auch die Berechnung.
Bei deinem IKU ist das hintere Beinpaar noch Seitenverkehrt montiert, was die Berechnungen noch etwas komplizierter macht.
Wünsche Dir noch viel Erfolg und bin jetzt auch wieder etwas mehr dabei.
Leider bin ich Zeitlich so eingespannt, dass eine Antwort schon mal etwas länger dauert.

Hoffe ich konnte Dir helfen
MfG
Roland

[HeXPloreR]

Hallo Roland, schön was von Dir zu hören...




Ist denn wirklich schon wieder ein Jahr um?
jepp, ein Jahr ist wieder rum...man das ging echt schnell ;)



Wenn ich den Bot um die X Achse habe "kippen" lassen, wobei die x-Achse genau durch den Mitte der beide mittleren Beine geht, dann:
Bewegen sich die vorderen und hinteren Beine exakt umgekehrt mit den gleichen Werten.(Vorne Bot hoch , hinten Bot runter) und die mitteren Beine stehen auf der Stelle.


Leider kann das nicht sein, dass er einfach da auf der Stelle steht. Weil sich beim senken und heben in einem Winkel der Fußpunkt ändern muss. * : Also ich denke Du machst es also auch schon richtig - nur wie war mir nicht ganz klar.
Das einzige was ich mir mitlerweile vorstellen kann wie man es lösen kann, wäre die Verkippung nicht in die mittleren Beine einzurechnen sondern in die Vorder und hinteren je nach dem in welche Richtung gekippt wird, weil diese Beine es besser ausgleichen könnten. Das bedeutet ersteinmal ich rechne es schon mal falsch an dieser Stelle:/

Ich habe nur Probleme an dieser Stelle mit dem kippen nach vorne und hinten. Zur Seite passt alles.

Viele Grüße
Jörg

[HannoHupmann]

Ich brechne alle Beine gleich. Macht es einfacher. Beim Kippen um die x-Achse kommt als delta Höhe für die mittleren Beine eben 0 raus, damit bleiben sie auf der gleichen Position. Diese "Besonderheit" wird also von der hinterlegten Mathematik ganz von allein erschlagen. Um die Mathematik aufzustellen habe ich mir das immer auf einem Papier aufgemahlt und die Formeln aufgestellt. Danach die Formeln mit einem weiteren Beispiel überprüft. Da Kippen um x und y-Achse jeweils eine Höhenänderung bewirken hat also jedes Bein: dh = dh1 + dh2 (wobei dh1 z.b. kippen um x-Achse und dh2 kippen um die y-Achse bedeutet).

Im Prinzip könnte ich damit auch um die Y-Achse kippen, wenn diese nicht genau in der Mitte (im Schnittpunkt der mittleren Beine) liegt sondern nach vorn oder hinten verschoben ist.

Alternativ kann man für die y-Achse auch ein vereinfachtes Modell verwenden, wo man nur ein Bein berechnet und diesen Bein1, 2 = dh2 und Bein5,6 = -dh2 Wert verwendet und die beiden mittleren dh2 = 0 lässt.

[HeXPloreR]

Moin moin,

ja genauso mache ich es auch. Nur mit dem Unterschied das ich bisher eine extra Berechnung einschiebe um den Versatz zu berechnen und den dann ins Mittelbein einrechne.

Soweit ich jetzt verstanden habe kann ich es also nur so lösen, das ich den Versatz nicht ins Bein einrechnen sondern in den Körper. Der Körper kippt ja quasi nach vorne und zieht den "Roboternullpunkt" entsprechend des Winkels mit sich.

Konstruktiv bedingt ist es also nicht möglich den Nullpunkt zu fixieren ohne eine mechanisches schieben zu verursachen. Jedenfalls mit meiner Methode nicht.

Das bedeutet auch das ich mich bewusster vom Roboterkoordinatensystem aufs Weltkoordinatensystem begeben muss. Was ich bei den vorderen und hinteren Beine wohl tue, aber bei den mittleren Beinen fälschlicherweise ignoriert habe.
Einen gleichen Nullpunkt in beiden Systemen gibt es nicht, oder nur in einer Parallelstellung des Körpers zur (Welt)Ebene am Anfangspunkt. Zusätzlich wenn man davon ausgeht das der Roboter keine Schritte macht.

Ich bin mir nun sicher wo mein Fehler liegt und bedanke mich für den Gadankenaustausch.

Viele Grüße
Jörg

[HannoHupmann]

Ich bin mir zwar nicht sicher ob ich deinen Gedanken folgen kann, aber schön wenn wir helfen können. Meine Berechnung sind so aufgebaut, dass er die Kipp und Nick-Bewegungen auch wärend dem Laufen ausgleichen kann. Bisher habe ich das aber noch nicht praktisch getestet, denn ich müsste erst noch den Gyro implementieren. Allerdings brauch ich für diesen erst noch ein Matlab skript um die Werte kontinuierlich auszulesen, zu filtern und als grafik anzeigen zu lassen. Gerade an letztem scheitere ich aktuell. So ein schöner, durchlaufende Plott will mir nicht gelingen. Wobei ich es bisher noch nicht mit Simulink versucht habe, sondern nur über die GUI gearbeitet habe.

[HeXPloreR]

...
Bei deinem IKU ist das hintere Beinpaar noch Seitenverkehrt montiert, was die Berechnungen noch etwas komplizierter macht.
...
Naja, die IK-Berechnung ändert sich dadurch nicht. Ich berücksichtige die jeweilige Einbaurichtung erst einen Schritt vor der SD21-Werteübergabe indem ich von 1500 (neutral) abziehe oder dazurechne.

Ich habe das vorher gesagt nun zeichnerisch umgesetzt, dabei funktioniert der alternative Ansatz den HannoHupmann angesprochen hat nur wenn man zusätzlich die Längenänderung für diese Richtung beim kippen mitberücksichtigt damit alle Fußpunkte am selben Ort bleiben. Tut man das nicht landet man ungefähr bei dem Problem welches ich gerade schon habe.
Es entsteht also z.B. beim kippen nach vorne zusätzlich auch ein Differenz die von den vorderen Beinkoordinaten abgezogen und auf die hinteren Beinkoordinaten aufaddiert werden muss. Bei meinem Roboter ist das die Y-Länge. Diese Differenz ist umso gößer je höher der Roboter steht bei gleichem Kippwinkel. Dabei verschiebt sich der Roboternullpunkt nicht nur im Bezug zum Weltkoordinaten des Kippwinkels nach vorne, sondern es fällt die Höhe ab wenn man die Mittelbeine auf "dh2" = 0 belässt. Da dieser Höhenabfall sich gleichzeitig auf alle Fußpunkte bezieht kann er vermutlich vernachlässigt werden - könnte aber auch korrigiert werden.. Ob und wie sich das auf den Kippwinkel zur Seite auswirkt werde ich mir ansehen müssen.

Jetzt gilt es also das ganze programmiertechnisch am Roboter nachzuprüfen.

[HeXPloreR]

Hallo Leute,

ich habe nun endlich Mal einen guten Aufbau der Platinen für meinen Hexapod zusammen gesetzt.
Hier sieht man eine SSC-32 gepaart mit dem neuen Raspberry Pi 2 und dem Robotis OpenCM9.04 B Board.
2991429915

Heute werde ich mich mit der ordentliche Verlegung der Leitungen beschäfftigen.
Sowie an der Software auf dem CM9 mit der inversen Kinematik weiter arbeiten.

Viele Grüße
Jörg

[HannoHupmann]

Wozu brauchst du den OpenCM9.04 B? Erschließt sich mir nicht ganz, warum man einen weiteren Controller benötigt.

[HeXPloreR]

Ganz einfach eigentlich Hanno,

auf dem Pi2 soll (es läuft darauf noch nichts - weil ich noch kein Image dafür gezogen habe) nur eine Facedetection laufen.
Vielleicht, aber nur vielleicht, probiere ich später dann mal meine iK in Python oder "C" auf dem PI zu schreiben, aber momentan schreibe ich sie in Arduino-C auf dem CM9. Der CM9 soll dann nur noch den X und Y Wert des erkannten Gesichts vom Pi2 empfangen.
Die SSC wird vom CM9 über UART bedient. Der Grund dieser Konstellation ist einfach der das ich dem Pi den Takt von 72MHz (wie der CM9 hat) nicht recht zutraue - obwohl der Pi2 es schon eher könnte.

Viele Grüße
Jörg

[HannoHupmann]

Huch? Das Pi hat 900MHz in der Version, meine ich gelesen zu haben. Da sollte die Leistung aber dicke ausreichen für alles. Klingt für mich ein wenig umständlich, zumal bei jedem zusätlichen Board wieder Signallaufzeiten in Form von Umsetzung hinzu kommt. Aber gut, die Architektur kann man so machen, ich würde es vermutlich ähnlich aufbauen, weil ich mir nicht zutraue das Pi so zu programmieren wie einen µC.

[HeXPloreR]

Huch? Das Pi hat 900MHz in der Version, meine ich gelesen zu haben. Da sollte die Leistung aber dicke ausreichen für alles.

Tja, das sind wir dann an dem Punkt wo ich sagen muss: "Kann sein, kann aber auch nicht sein".
Ich weiß nur das der alte Pi es nicht sonderlich schnell (3 - 6 Fps ) geschafft hat. Dem Neuen traue ich es eher zu, aber dazu müsste ich überhaupt erstmal wissen wie schnell er ein Gesicht findet.

Ist in arbeit.

Viele Grüße
Jörg

[HeXPloreR]

Juhu.... oder eher nicht :(- ich habe meine einzigen CM9 in den ewigen Bauteilehimmel geschickt.
Ich wollte gestern mal wieder was an der Programmierung machen, aber der Download des Programms bricht immer wieder ab.
Alles ausprobiert was ich dazu weiß - nichts zu machen, es meldet sich nicht mehr zurück.

Ich werde ein Neues bestellen müssen. Schade, aber nicht zu ändern.

Viele Grüße
Jörg

[HeXPloreR]

So der ne Controller ist sch da.
Jetzt habe ich bald keine Ausreden mehr parat wenn ich es nicht hinbekomme :nö:

Viele Grüße
Jörg

[HeXPloreR]

Hallo Robotikfreunde,

ich habe mich kurzfristig entschlossen schon einmal zwei gefräste Teile in meine IKU einzubauen.

Vielen Dank an den Fräser der wirklich wieder einmal sehr schnell und sauber gearbeitet hat.

Fotos: 2998929990


Viele Grüße
Jörg

[HannoHupmann]

Uh? Aus voll Aluminium? Ich hab für den Rahmen bisher immer Alu-Dibond verwendet. DAs ist zwar nicht ganz so stabil aber für die Hexas reicht es. Dafür ist es eben leichter.

[HeXPloreR]

Und wieder ein Open CM9.04 kaputt. Ich glaube bald die Dinger taugen einfach nichts. Wenn mir der Nächste jetzt auch wieder nach ein paar Tage und einigen Flashs wegstirbt dann sind die Robotisteile für mich endgültig gestorben. :MistPC

[Slowly]

Sehr ärgerlich Jörg. Hast Du in Ruhe die gesamte Spannungsversorgung und Massebeschaltungen durchgesehen?
Hab´ den ganzen Tag an der Elektrik am Motorrad eines Kumpels gearbeitet...
Erkenntnis: Man hätte gleich auf den Fehler kommen können wenn man nicht so kompliziert denken würde....

[HeXPloreR]

Ja, Slowly ...das habe ich alles gemacht. IDE Neustart, USB Kabel neu gesteckt, Reset Button gedrückt, Recovery Modus ausprobiert, PC Neustart - nichts ... einfach die gleiche Meldung wie bei dem zuvor: CPU meldet sich nicht-flash wird nicht durchgeführt. Gestern noch alles okay, heute erste Änderung im Code aufspielen ... geht nicht.:mad:

Ja wirklich manchmal echt ärgerlich wenn irgendwie nichts läuft.

Ich guck jetzt nen Film!!!

Viele Grüße
Jörg

[HeXPloreR]

Hallo Leute,

da ich keine Möglichkeit gefunden habe einen RC-Empfänger in den CM09 korrekt einzulesen, habe ich mich kurzerhand entschlossen zwei Dynamixel AX-12 damit auszulesen.
Hat etwas gedauert sich wieder in die Dynamixels reinzulesen und den passenden Code zu schreiben aber jetzt funktioniert es und damit habe ich nun eine Art Joystick zum steuern.

Sobald ich aus dem Bascomprogramm vollständig die inverse Kinematik ins "Arduino C/C++" übertragen habe, habe ich dann die Möglichkeit in der X- und Y-Achse richtig gut zu testen \\:D/
Vorallem kann ich jetzt noch mehr Parameter einfach durch hinzufügen von Dynamixels steuerbar machen.

Viele Grüße
Jörg

[HeXPloreR]

Okay Leute,

ich bin der Meinung die Open CM09.4 Boards sind schlechte Ware. Ich kann niemandem empfehlen die zu kaufen.

Leider hatte ich mich wirklich darauf gefreut das dieses Board schon von Haus aus die Dynamixels ansteuern kann. Und das es eine Arduino ähnliche IDE hat damit bin ich nun auch zurecht gekommen, ABER das diese Boards einfach plötzlich nicht mehr programmierbar sind, das ist echt zum im Kreis k*o*t*zen :mad: ...paar Tage klappt alles, und dann plötzlich .... WEG!!!!! :MistPC

Damit ist dann Board #3 innerhalb kürzester Zeit dahin geschieden. Also ich gebe es damit auf - nicht empfehlenswert.

Alternativen?? Raspberry PI 2 ?? Python oder "C" ....ja da freue ich mich drauf - wieder neu einarbeiten.

Ich bin richtig angepisst jetzt.

=;
Jörg

[Slowly]

Hui ! Solche Worte aus Deiner Tastatur ? ;-)
Nach diesem Problem habe ich auch gegoogelt und nichts
ähnliches an Problemen gefunden.
Kann es doch etwas triviales sein ?

[HeXPloreR]

Ich finde dazu auch nichst weiter. Außer die Verkäuferseiten. Zwei Einträge in Foren,und ein Projekt wo man auch nichst mehr hört.
http://forums.trossenrobotics.com/showthread.php?7205-OpenCM9-04-IDE-Problems/page2

Was sollte es triviales sein? USB angeschlossen, Gerät erkannt, Treiber deinstalliert neu installiert, Power LED leuchtet, flashen nicht möglich weil Board nicht reagiert.
Diese Boards sind einfach schlecht. Von schlechtem trenne ich mich einfach.

Ich lade jetzt noch die RoboPlus runter, und wenn da auch rein garnichts mit geht dann fliegen die Teile in die Tonne und fertig ist's.

Ich hab da echt keien Lust drauf und auch nicht wirklich so die Zeit für.

EDIT:
Peter schrieb im Fehlschlag der Woche:



...

1. Qualität: Kann an der Halbleiterqualität oder der Verarbeitung (z.B. zu heiss gelötet) liegen.
2. Nicht passender Programmieralgorithmus, das drückt die erreichbaren Programmierzyklen auch runter. Kann jetzt auch sein, dass du unglücklicherweise einen Ausreisser erwischt hast! Allerdings kann man auch einem einzelnen Exemplar nicht wirklich einen Rückschluss auf die ganze Serie machen.
3. Schlechtes Layout, bzw. Spannungsspitzen auf der Versorgungsspannung.
4. Dein Aufbau kann auch etwas ungeschickt sein. Wenn diese Board auf gewisse Störungen etwas sensibler reagiert und dein Aufbau genau diese Störungen begünstigt ...


ich tippe auf 1. und oder 2. - drei Boards defekt. Das erste aus GFrankreich, die anderen in Deutschland gekauft.

2. USB - Passende IDE Robotis v1.0.2
3. Boardlayout kann ich nicht beurteilen. USB-5V , interner Regler auf 3,3V im Board.
4. Es hängt ein Datenkabel extra dran damit die Dynamixels eingelesen werden können. Lief die ganze Zeit gut so.


Das letzte und 4. Board tut jetzt ganz jungfräulich seinen Dienst. Ich vermute mal das wird auch nicht lange halten ... ob ich mir das noch antue jetzt?
Allerletzte Chance.

Viele Grüße
Jörg

[HannoHupmann]

Sowas ist ärgerlich und ich kenne das von meinen Servos die ich bei meinem Hexa verwende. Die sind auch immer reihenweise gestorben. Jetzt langsam habe ich die wenigen herausdestiliert die taugen und keine Montagsproduktion sind. Zur Sicherheit habe ich die kritischen Schultergelenke durch andere Servos ersetzt.

Ich würde das jungfräuliche Board zurückgeben oder verkaufen, denn damit willst du ja eh nicht mehr arbeiten.

[HeXPloreR]

Hallo Hanno,

das Problem ist leider das ich es zeitlich nicht schaffen werde, wenn ich jetzt wieder umswitche auf ne andere Hard-/Software, überhaupt etwas funktionierendes auf den Tisch der Maker Faire zu stellen.

Deshalb werde ich wohl oder übel weiter damit machen - auch wenn ich alle zwei Wochen drei neue Boards kaufen muss - wären dann ja nur ungefähr 12 Stück ... :-k

[malthy]

Hi Jörg,

das klingt ja schrecklich! Kaufst Du die Boards immer neu oder läuft das dann jeweils unter Garantie? Ich kenne das Board überhaupt nicht, bin aber ehrlich gesagt etwas skeptisch, ob das Board als solches so schlecht ist, dass es so schnell kaputt geht. Selbst einem nackten Controller ohne irgendwelche Schutzbeschaltung muss man ja ganz schön Gewalt antun, bis er kaputt geht. Was nicht heißt, dass mir das nicht schon vielfach gelungen ist ... Wenn ich das richtig sehe ist Dein Board von Robotis und man hat doch schon den Eindruck, dass die Wissen was sie tun. Wäre das Board aus einer Kickstarterkampagne von einem 17 Jährigen hervorgegangen, wäre es was anderes, aber so? Und würde das Board als solches so schnell sterben, würde man davon doch mehr im Netz lesen (falls Du nicht der einzige bist der es benutzt ;-)). Und drei mal in Folge zufällig ein fehlerhaftes Board? Hmm ... Also langer Rede kurzer Sinn: kann nicht doch irgendein Detail Deines Aufbaus Schuld sein?

Ich kann mich bei mir an zwei zumindest ähnliche Fälle erinnern. In einem Fall war es ein Aufbau mit einem AVR bei dem ein GLCD die ISP Pins mitgenutzt hat. Nach ein paar Mal flashen war der Controller tot. Problem war da offenbar, dass das LCD das Flashen gestört hat, weil R/W und CS vom LCD nicht die korrekten Pegel hatten. Ein paar Pull-Ups haben das mehrfache AVR-Sterben dann beendet. In einem anderen Fall war es ein relativ teueres FPGA-Board (Nexys 2), dass ich plötzlich nicht mehr per USB kontaktieren konnte. Glücklicherweise wurde mir das Board ersetzt. Da war es mit höchster Wahrscheinlichkeit so etwas triviales wie ein defektes USB Kabel (der gute alte "Wackelkontkakt"), das ich zum Programmieren benutzt habe.

Vermutlich hilft's nicht weiter, aber ich kann irgendwie nicht glauben dass es nur am Board liegt ...

Gruß
Malte

[HeXPloreR]

Hallo Alle zusammen,

ich habe nun die inverse Kinematik auf das neue Programm übertragen. Alle Servos sind in ihrer Einbaurichtung überprüft und ein abschliessender gesammt Test ob alles Richtig rum dreht ist gemacht.
Damit bin ich nun wieder auf dem Stand von meinen Bascom-Programm welches vorher auf dem Hexapod lief.
Also vorerst eine einfachste Umsetzung von Fußkoordinaten in Winkel für die Servos. Das sah mal z.B. so aus -->> https://www.youtube.com/watch?v=RvxNyNZ4aUg <<--
Mittlerweile hab ich auch die Servokabel besser unter Kontrolle.

Als nächstes werde ich nun meine "Theorie der Achsendrehung" versuchen programmiertechnisch umzusetzen.

Und ja, das letzte Board tut noch seinen Dienst - noch. :pray:

Viele Grüße
Jörg

[HannoHupmann]

Ich würde die Fussservos um 180° drehen, so dass die Achse oben ist. Macht keinen großen Unterschied, was die Kräfte angeht, aber der Roboter hat damit etwas mehr Bodenfreiheit.

[HeXPloreR]

Ich würde die Fussservos um 180° drehen, so dass die Achse oben ist. Macht keinen großen Unterschied, was die Kräfte angeht, aber der Roboter hat damit etwas mehr Bodenfreiheit.

Wenn ich mehr Bodenfreiheit wollte dann hätte ich die Beine länger gemachen. Der Unterschenkel ist mit Fußspitze jetzt 125mm lang. Und für meinen Geschmack damit schon etwas zu lang - nicht das ich im allgemeinen was gegen lange Beine habe ... ;)- Aber alleine durchs drehen würde das Bein im 20mm länger werden.
Ich finde das muss nicht sein - hier eher 20mm kürzer.

[HannoHupmann]

Dann mach die Füße kürzer und spar dir das Gewicht! Im Moment verschenkst du 20mm ohne Nutzen!

[HeXPloreR]

Hanno, ich kann mich mit der Idee irgendwie nicht anfreunden.

Es zerstört 1. das schöne Design ...und 2. und viel wichtiger kann ich dann die Servos nicht mehr übereinander fahren. Dazu müsste ich wieder den Oberschenkel verlängern oder auch die dazu gehörenden Servos umdrehen. Wenn ich die Füße kürze, wo bleibt dann Dein erster Einwand mit mehr Bodenfeiheit?
Wieviel Gewicht verschwende ich denn - 5g pro Bein?!

Dass das in dem Bauzustand überhaupt nicht mehr in Frage kommt sollte Dir als langjähriger erfahrener Hexapodbauer klar sein.
30061

Viele Grüße
Jörg

[HannoHupmann]

Zum Design sag ich nichts.
"Übereinander fahren" müsste trotzdem gehen, nur vielleicht nicht ganz so eng.
Die Füße kürzen bezog sich natürlich auf deinen Anspruch, den Körper nicht so hoch zu setzen.
Ich denke es dürften mehr als 5g sein, vermutlich eher 10g. Das wären dann schon knapp 2Ncm die man an der Schulter einsparen kann. Viele kleine Einsparungen von wenigen Gramm machen es am Ende aus.
Allerdings ist es weniger die reine Gewichtsersparnis die bei den Beinen entscheidend ist. Vielmehr reduziert sich damit auch die Massenträgheit und die stört beim schnellen Laufen gewaltig.


Als langjähriger Hexabotbauer ist mir klar, dass ich das Design zu JEDER Zeit komplett Ändere, wenn es mir einen Vorteil bringt.
Vielleicht hast du meine Threads nicht genau in erinnerung, aber sowohl beim Phoenix, als auch bei meinem Vinculum habe ich die Konstruktion der Beine noch sehr, sehr oft verändert, obwohl der Hexa bereits komplett fertig war.

[HeXPloreR]

Wo hatte ich denn aktuell überhaupt ein Problem der Bodenfreiheit angesprochen? Kannst Du dazu bitte kurz zitieren woher Du das hast.
Und schnelles laufen? - laufen irgendwann irgendwie ja, aber schnelles. Soweit ich meine Threads kenne habe ich schon bei der Planung des Designs diesen Aspekt "des schnellen laufens" berücksichtigt und somit nicht geplant.




Als langjähriger Hexabotbauer ist mir klar, dass ich das Design zu JEDER Zeit komplett Ändere, wenn es mir einen Vorteil bringt.
Vielleicht hast du meine Threads nicht genau in erinnerung, aber sowohl beim Phoenix, als auch bei meinem Vinculum habe ich die Konstruktion der Beine noch sehr, sehr oft verändert, obwohl der Hexa bereits komplett fertig war.
Aber man ändert nicht in einer Phase der Programierung nochmals einen Aufbau der keiner Änderung bedarf.
Wenn es um ein mechanisches Problem ginge, würd ich Dir recht geben. Aber da die Beine nicht bautechnisch mechanisch überladen sind ist auch keine Korrektur am Material nötig.
Soweit ich noch weiß hattest Du erhebliche Problem mit den von Dir geplanten Beinen in der Umsetzung.

Bei Detailverbesserung oder Erweiterung der Funktionalität behalte ich mir selbstverständlich vor betroffen Teile neu zu planen.

Ich habe hier übrigens irgendwo ein schönes Bild gefunden das alle relevanten Daten der IK des Beinse ab der Hüfte auch sehr gut darstellt:
30062

[HannoHupmann]

Die Anforderung habe ich nicht aus deinem Thread, das ist einfach eine generelle Anforderung, allerdings je nach Hexabot mehr oder weniger wichtig. Fakt ist einfach, dass du mit der Konstruktion im Moment unnötiges Material herumträgst, dass sich auf das Gesamtgewicht und die Massenträgheit auswirkt. Zudem könnte man durch drehen des Fußservos die Fußlänge verkürzen, bei gleichbleibender Bodenfreiheit. Dies hat den Vorteil, dass die Füße stablier werden. Unterm Strich habe ich eine Optimierung aufgezeigt, die mir aufgefallen ist. Umsetzen muss man sie nicht, man könnte es.

[HeXPloreR]

Hallo Roboterfreunde,

jetzt funktioniert die Körperdrehung um die X- und Y-Achse endlich zufriedenstellend. Das von mir erwähnte "Schiebe-Problem der Mittelbeine" ist hier nicht mehr zu beobachten.

Ich habe nun aus der Drehung der X-Achse das "hy" und das "hx" der Y-Achse als tangenzialen Bezug zur x- und y-Koordinate des Fußpunktes aus dem Robotermittelpunkt. Hier wird nun hx und hy jeweils auf die Ursprungshöhe "Tz" addiert oder subtrahiert.
Um die Drehung des Körpers von den Beinen weiter abzukoppeln, wird der Cosinus des Winkels mit den jeweiligen Körperlängen verrechnet und das Ganze anschliessend von den Koordianten des Fußpunkts abgezogen.
Die unter anderem hieraus entstehenden Werte für x-, y- und z-Koordinate des Fußpunktes fliessen dann direkt als Übergabewert in die inverse Kinematik ein.

Die Drehung der Z-Achse habe ich dabei irgendwie vernachlässigt. Kommt die Tage aber sicher dazu.
Die Überlegungen dazu sind gemacht und müssen noch programmiertechnisch umgesetzt werden.

Viele Grüße
Jörg

[HeXPloreR]

Hey,

ich habe nun die Facedetection auf dem RasPi-2 mit einer WEB-Cam am laufen. Es wird jetzt etwa zwischen 28 - 35ms ein Gesicht gefunden. Das wären dann etwa 35 - 28Fps. Die Auslastung der CPU's wird mit 20 - 30% angezeigt. Ich finde damit lässt es sich gut leben.
Jetzt muss das Ganze noch in den OpenCm9 per UART übertragen werden. Und der muss es auswerten.

Viele Grüße
Jörg

[HeXPloreR]

Hallo an alle Mitlesenden,

nun ist der Kopf von "IKU" per Facedetection steuerbar. Die Steuerung ist zwar noch nicht ganz ausgereift, aber prinzipiell funktioniert's.

Jetzt kann ich mich daran machen den Körper einzubinden, damit Dieser auch leichte Bewegungen mit ausführt.

Viele Grüße
Jörg

[HeXPloreR]

... . Kaufst Du die Boards immer neu oder läuft das dann jeweils unter Garantie? ...

Hallo Malte,

ich habe die zwei defekten Boards heute getauscht bekommen. Das dritte der Reihe tut seinen Dienst, in der gleichen Umgebung wie die Anderen auch hätten tun sollen, immer noch ganz brav.

Viele Grüße
Jörg

[HeXPloreR]

Hier mal ein kleiner Appetizer für die Maker Faire 2015 in Hannover:
30254
see you soon....

Jörg

[Slowly]

Vielen Dank für die Vorführung Jörg !
Da werden einige Leute Augen machen.
Großen Respekt was du da hinbekommen hast.

Jørgen

[HeXPloreR]

Vielen Dank für die Vorführung Jörg !
Da werden einige Leute Augen machen.


Immer wieder gerne :) Vielen Dank, Jørgen.

Das war Sie nun - Die Maker Faire 2015 in Hannover (Video-Youtube) (https://www.youtube.com/watch?v=lSg1WAu6XeE) - wir sind nächstes Jahr wieder mit dabei.
Es war ein super Wetter - wie gemacht für unsere Projekte. Einfach nur Toll.

Vielen Dank an alle inetressierten Besucher und Aussteller.

Es ist immer wieder schön zu sehen wie mit der IKU "gespielt" wird ;)
Die Facedetection hat super funktioniert. Keine einzigen Ausfall am Roboter zu beklagen. Alles hat super geklappt.

Hier ein paar Bilder vom Roboter:
3027330274

Viele Grüße
Jörg

[HeXPloreR]

Hier mal ein paar Ampere-Werte für Interessierte mit einem einfachen trägen Multimeter gemessen:

0,13A nur für die Elektronik, ohne Servos, ohne den Pi2
ca. 0,43A im Stand mit Servos, ohne Pi2
ca. 1,8A mit fahrenden Servos und Pi2

Viele Grüße
Jörg

[HeXPloreR]

Hallo zusammen,

auch wenn es doch schon sehr sehr lange her ist das ich hier was geschrieben habe ...
Das Projekt lebt noch !!

Diese Seite ist im Aufbau:
https://HeXPloreR's Corner.de
See ya at the Maker Faire Hannover 2023
(https://hexplorerscorner.de/)
35949
Viele Grüße
Jörg