Oktopod Projekt

mehr = besser = schwerer = schlechter :p gibt immer zwei Seiten einer Medaille. Du musst durch Messen und Probieren den Spannungseinbruch so Gering halten, dass er für dich Akzeptabel ist und die Servos gut funktionieren.

Ich würde es anders machen, die Servokabel so weit kürzen, dass sie die Volle beweglichkeit zulassen, aber nur bis zur Schulter kommen, dort dann pro Bein eine Kleine Elko Batterie mit 2000µF (oder 6800, dann hab ich das aus Hannos thread wohl auf die schnelle falsch verstanden) und das Controllerboard nur über Masse und Servosignal mit den Servos verbinden. Und die Elko Batterie wird dann direkt vom BEC versorgt ( ein Ring um einen Bot herum mit 6V für die Servos). Das wäre mMn. die sauberste Lösung, muss aber auch im Bot untergebracht werden können. Ansonsten ist eine große zentrale Elko-Batterie wie bei Hanno natürlich auch möglich.

E: @Geistesblitz: Die Kondensatorbank kommt hinter den BEC (also auf die Servo-Seite). Die Versorgung wird ja schon durch die Batterie (riesiger Kondensator, wenn man so will) gut genug geglättet.

Ok, danke erst mal an alle! :)
@Hanno: Ich hatte deine Megapost nicht gelesen, meine Fragen bezogen sich nur auf Robin, nach deinem Post hab ich dann meins wieder gelöscht und andere Fragen reingeschrieben... klassisches Timingproblem :-p

- - - Aktualisiert - - -

Ok, eine Frage hab ich noch: :rolleyes:

So ein DC/DC Wandler mit einem Elko ist doch im Grunde das gleiche wie ein BEC - oder?
Ich würde nämlich eher zu meinem vorhandenen (kleinen) BEC für die Elektronik tendieren, da ich zumindest bei Conrad nur DC/DC Wandler bis 1.5A gefunden habe.

@robin, im Prinzip habe ich deine Idee umgesetzt. Zumindest soweit das bei dem Bauraum möglich ist. Die Servos werden an der Schulter eingesteckt, die Steuersignale und GND gehen zum µC und die Leistungsversorgung erfolgt über dicke Kupferleitungen zur Schulter. Kabel sind alle so kurz wie möglich gemacht und von der Kondensatorbank geht die Verteilung quasi Sternförmig.
Akku --> SBEC --> Kondensatoren 6x6800 --> Schulterverteilerknoten 100nF + 100µF <-- Servos
Ich hatte auch mal mit einer Ringverteilung gespielt, aber damit war ich nicht zufrieden.

Keine Ahnung wie viel Strom deine Elektronik zieht, vermutlich mehr als meine, daher wäre es mit einem BEC schon in Ordnung (ja ist genau das gleiche). Meine Logik kommt bisher auf 230mA also reicht ein DC/DC mit 1A dicke aus.

Stromversorgung der Logik und der Servos vom selben Akku: wer das "einfach so" anklemmt wird feststellen, dass die CPU auf dem Logikboard immer wieder Aussetzer hat und Resets durchführt. Schlimmstenfalls zerstört man den Controller. Der Grund ist simpel: die Servomotoren ziehen nicht nur eine Menge Strom, sie geben auch tonnenweise Störungen auf die Leitung zurück. Das liegt an den Bürsten in den Motoren, die unberechenbare Abreissfunken generieren und an den Impedanzen und Kapazitäten im System. Ausserdem saugen bei einem Laufroboter meist viele Servos gleichzeitig viel Strom, so dass die Spannung am Akku auch schon einmal wesentlich zusammen brechen kann.

Die einfachste Lösung, die ich für meinen Hexapod und meinen Octopod gefunden habe, basiert auf eine NiCad Akku mit 7,2V und ein paar Ampere. NiCad's sind "late" Technologie, funktionieren aber auch.

Der Akku versorgt direkt alle Servos mit einer Verteilung mit üppigen Querschnitt. Zusätzlich kann man vor das Servo noch einen oder mehrere Kondensatoren hängen, um die Leitungen zu entlasten. Hier sind allerdings recht hohe Kapazitäten nötig.

Der Servocontroller hängt an den selben 7,2V, die fogendermassen gefiltert werden:

Code:

---


.                            +--------+
. + -------/\/\/\---[>|--o----| 5v REG |------o-----o-------> CPU
.                        |    +--------+      |    | 
.                      ---      |          ---  ---   
.                      ---      |          ---  ---
.                        |        |          |    |
. - ---------------------o--------o-----------o-----o-------> GND


---

Der Filter hatte IIRC 100uH und dient dazu, die hochfrequenten Störspitzen zu filtern. Die Diode ist das Magische Schwert. Sie sorgt dafür, dass die Motoren nicht den Strom aus den folgenden Pufferkondensatoren ziehen. Der erste C filtert die niederfrequenten Spitzen und muss passend zum Regulator und dem Verbraucher dimensioniert sein. Der zweite und dritte C unterstützt den Regulator.

Wenn das nicht reicht, dann schaltet man zum ersten Kondensator noch einen zweiten mit einem *anderen* Wert parallel (also z.B. 2200yF parallel mit 47uF, vielleicht noch mal 1uF). Die unterschiedlichen Kapazitäten addieren sich nicht nur einfach auf, sondern die Kondensatoren laden und entladen sich unterschiedlich schnell, so dass jeder Kondensator einen anderen Frequenzbereich der Störungen ausfiltert.

Verstanden soweit, bleibt für mich eine Frage: Was für eine Diode setzt man da am besten ein? Ich würde nämlich gerne so eine Schaltung bei meinem Vinculum einbauen.

Puh, Hanno, das weiss ich nicht mehr. Der Schaltplan ist irgendwie auch nicht mehr auf meinem Rechner. Das ist aber auch recht unkritisch. Jede Diode, die in Durchflussrichtung den Strom aushält, den der Controller benötigt +100% Sicherheit, + Versorgungsspannung x1.5, sollte reichen.

Der Filter wäre dann sowas?
http://www.conrad.de/ce/de/product/4...f=searchDetail

Das gibt's auch kleiner und billiger. Such mal nach Festinduktivität oder Drossel. Hängt halt vom Strom ab, den Du brauchst:

http://de.farnell.com/murata-power-s...ded/dp/1710416

oder noch kleiner für 18 Cent:

http://de.farnell.com/multicomp/mcal...mhz/dp/1839648

Schau halt, dass der Widerstand nicht zu hoch ist.

Für meinen Elektronik Kram brauche ich ein gutes Ampere, daher die fette Spule. :-)

So, ich hab mal mit der Schultergelenkkombination angefangen, so dass Standard-Servos reinpassen.
Leider musste ich feststellen, dass auch bei Standard-Servos die Löcher nicht genormt sind. :mad:

D.h. die Details mach ich erst, wenn die Turnigys ankommen.

Bild hier  

Im Gegensatz zur alten Spinne mit hitec-Robot-Servos hat sich der Abstand zwischen den Aufnahmen nur um 4mm vergrößert.

Ein neues Bein-Konzept steht, im Prinzip so, wie die meisten Hexa-Beine aufgebaut sind, nur halt mit 3D-Teilen.
Bild hier  

Die Beweglichkeit ist auf diese Art super. Rechts ist das Bein am extremsten zusammengefaltet. Bodenabstand Schultergelenk <-> Kontakt Fuß: 4,6cm.
In der Mitte ist ein realistischer Abstand: 7,6cm und ganz links wäre meine Wunschvorstellung, die noch funktionieren sollte: 14,76cm.

Bevor mir jetzt Hanno vorrechnet, dass das alles nicht klappt, komme ich ihm zuvor... ;-)
Die Servos sind mit 12,25kg/cm bei 6V angegeben. D.h. Hubkraft in der mittleren Position 12,25 * 0,8 (wegen Hub) / 7,6 = 1,29kg.
Ich schätze den Bot diesmal auf knapp 3kg. Wenn sich die Beinpaare paarweise bewegen sollen, muss auf einer Seite jeweils alles durch ein Bein gehalten werden = 1,5kg.
An dieser Stelle kann man also schon von einem Griff ins Klo sprechen.

Baue ich aber einen Okto und gehe mal von 3,5kg aus, wegen der 2 zusätzlichen Beine, dann sieht die Rechnung besser aus:
3,5kg, davon die Hälfte, verteilt auf 2 Beine = 0,875kg Last pro Servo. Damit hätte ich 47% über dem Minimum.

Das ist allerdings nicht viel. Da ich den Anspruch habe, dass er auch etwas steigen soll (keine Treppen, aber Treppchen...) dann ist da vermutlich schnell Ende im Gelände.
Ebenso darf man dann auch nicht die Dreh-Servos vernachlässigen. Wenn sich der Bot "nur" nach vorne bewegt, haben die Servos nicht viel zu tun. Bei einer Steigung oder bei Gefälle müssen diese aber ebenso mitarbeiten.

Lange Rede... falls die 12kg Servos schlapp machen, werde ich wohl für die Drehgelenke und die Schultern diese Servos nehmen:
http://www.hobbyking.com/hobbyking/s...arehouse_.html
...die machen dann 27kg/cm bei 6V. = 225% über dem Minimum und bei der weiten Position (links im Bild) immer noch 67% über dem Minimum.

Morgen werde ich außerdem noch mal gucken, ob ich das Gummi - oder Federkonzept an den Beinen noch eingebaut bekomme...

Hallo,

ich würde den Unterschenkelservo in dieser Version direkt in den Unterschenkel setzen. Und hier vielleicht einen gewinkelten Anschluss zum Fußsegment planen.

Viele Grüße

So wird das meistens gemacht - aber wieso?

Ansonsten geht ja eine Führungsstange nach oben. Das Fußelement geht quasi bis oben hin.
Ich hab mir gedacht, dass es besser ist, möglichst viel Gewicht nah am Körper (Schultergelenk) zu haben, um dieses zu entlasten - wenn auch nur mit minimaler Wirkung.

Seh auch keinen Vorteil darin, der Servo weiter nach außen zu ziehen. Das wird doch hauptsächlich nur wegen der Fertigung gemacht und da hast du mit 3D-Druck ja keine/kaum Probleme.

Wie stabil ist eigentlich das Plastik, dass du da Drucken lässt?

Sehr stabil. Es ist quasi Nylon.
Bei shapeways nennen die es Strong & Flexible, das ist es auch.
D.h. wenn es dünn ist, kann man Federn oder Schnappverschlüsse, etc. damit bauen.
Es hat jedenfalls nichts mit billigem Plastik zu tun.

https://www.shapeways.com/materials/...plastic?li=nav

Zitat:

---

Bevor mir jetzt Hanno vorrechnet, dass das alles nicht klappt, komme ich ihm zuvor... :wink:
Die Servos sind mit 12,25kg/cm bei 6V angegeben. D.h. Hubkraft in der mittleren Position 12,25 * 0,8 (wegen Hub) / 7,6 = 1,29kg.
Ich schätze den Bot diesmal auf knapp 3kg. Wenn sich die Beinpaare paarweise bewegen sollen, muss auf einer Seite jeweils alles durch ein Bein gehalten werden = 1,5kg.
An dieser Stelle kann man also schon von einem Griff ins Klo sprechen.

---

Der Hanno rechnet das aber trotzdem noch mal nach, denn ganz richtig ist es leider nicht. Denn dein Roboter könnte in der oben genannten Konfiguration 3,87kg schwer sein. Kleiner Exkurs: Es gibt für einen Hexa drei mögliche Lauf-Algorithmen: 1) 5 Beine auf dem Boden 1 in der Luft, das Gewicht teilt sich auf 5 Beine auf. 2) 4 Beine auf dem Boden 2 in der Luft, Gewicht / 4 oder 3) 3 Beine Boden, 3 Beine Luft das Gewicht teilt sich auf 3 Beine auf, wie in deinem Fall. Niemals aber kann sich die Gewichtskraft einseitig aufteilen wie bei dir gerechnet. Die 3 Füsse auf dem Boden bilden ein Dreieck und dessen Schwerpunkt ist irgendwo in der Mitte, d.h. die Gewichtskraft teilt sich homogen auf alle Beine auf, außer: der Roboter hat Schlagseite! Bei 1,5kg auf einer Seite muss er aber schon sehr starke Schlagseite haben und dann kippt er vermutlich eh um.

Für Treppensteigen würde ich auf Algorithmus 1 zurück greifen und mit 5 Beinen den Roboter stabilisieren. Bei meinem Vinculum habe ich die Programmierung so aufgezogen, dass ich beliebig zwischen den Algorithmen wechseln kann. D.h. im Moment kann ich 2 Schritte mit 5:1 laufen und dann auf 3:3 wechseln, wenn der Weg frei ist und es schnell voran gehen soll.


Wenn man schon druckt und dafür viel Geld ausgibt dann sollte der Oberschenkel besser designed sein, denn dieses Design, wird von allen nur deswegen verwendet, ist für die Herstellung aus Plattenmaterial gedacht. Dabei ist es schwierig das ganze verwindungssteif auszuführen. Abgesehen davon könnte man zur Gewichtsersparnis gleich noch ein paar Aussparungen ein designen.

Der Servo wird in den Oberschenkel gesetzt damit so wenig Masse wie möglich an der Fusspitze ist, denn je weiter draußen die Servos desto mehr Hebelarm für die Schulter beim anheben. Das fällt bei diesen Servos zwar nicht ins Gewicht, denn Drehmoment ist genug da, aber: 1) Masse ist immer Träge und der Roboter tendiert dazu mir ihr zu wackeln und 2) je weniger Energie für sowas verbraucht wird, desto länger "läuft" der Roboter. Unterm Strich sollten die Servos also so nah wie möglich am Körper sein!

Ich dachte so, das Servo in der Ansicht ganz rechts um ca 50° (oder was auch immer der winkel aktuell wäre) im Uhrzeigersinn zu drehen. Damit hättest Du vermutlich etwa das Gewicht der "Führungsstange" eingespart. Das "Haltergehäuse" dann in der Verlängerung vom Fuß (ohne diesen Winkelansatzl).
Der Grund warum ich das Voschlug ist einfach der dass das Material ja nun auch Geld kostet, und je weniger man davon benutzen muss, weil man ein Servogehäuse integriert umso besser. Außerdem das Gewicht der Servos hast Du immer - da kann man nicht mehr viel dran machen.

Oder wie Hanno gut angedeutet hat zwecks noch bessere Massenverteilung in den Oberschenkel setzen (den Gelenkanschluss dort quasi umkehren) Hier hättest Du dann den Vorteil dass das Kabel über eine Gelenk weniger geführt werden könnte. Und den Platz dafür hast Du anscheinend auch.

Hm... stimmt. Zumindest, wenn man darauf achtet, dass man die Beine so anordnet, dass die 3 Beine, die auf dem Boden sind, ca. 120° bilden. Je näher die 2 Beine, die auf einer Seite das Gewicht tragen, zusammen stehen, desto schwerer wird es für das eine gegenüberliegende Bein. Ein anderer Punkt ist aber, dass sich ja der Robot während des Schritts verschiebt, d. h. beim Schritt nach vorne ist der Schwerpunkt auch weiter vorne und die vorher beschriebene Ideal-Konstellation wieder über den Haufen wirft.

Im idealen Fall wäre ich beim Hexapod 30% über dem Minimum. Wie weit ich mich vom Ideal entferne, hängt von den Schrittweiten ab, auf alle Fälle wird es ziemlich eng.

Auf alle Fälle hat mir die Rechnung gezeigt, dass der Vorteil durch einen Oktopod nicht mehr so groß ist. Ich sollte wohl direkt die Schulter-Servos stark auslegen.

Zum Bein-Design: Form follows function. Ich hab beim Oberschenkel sogar mit graden Platten angefangen. Da die aber beim Hochfahren an den anderen Servoträger gekommen sind, ist die leichte Kurve drin.
In der Mitte brauche ich Luft, damit die Servos durchschwingen können, da ich auf alle Fälle mit einem Gegenlager arbeiten möchte. In der Mitte sind 2 gebogene Platten. Man sieht es in der Darstellung nicht so gut, aber da passen die Servos genau durch.
Mehr Platz ist in der Mitte nicht vorhanden. Die Aussparungen mache ich allerdings noch.

Servo in den Oberschenkel - das ist bei der Konstruktion durch das Gegenlager und damit 2 Platten nicht möglich. (Außer, die Gabel verjüngt sich wieder zu einer Platte, aber dann ist die Servoplatte für den Unterschenkel nicht in der Mitte, ...usw.) Allerdings ist diese Stellung normalerweise noch besser, da so noch mehr Gewicht näher am Körper ist.

Zitat:

---

Zitat von LeeMajors

Hm... stimmt. Zumindest, wenn man darauf achtet, dass man die Beine so anordnet, dass die 3 Beine, die auf dem Boden sind, ca. 120° bilden. Je näher die 2 Beine, die auf einer Seite das Gewicht tragen, zusammen stehen, desto schwerer wird es für das eine gegenüberliegende Bein. Ein anderer Punkt ist aber, dass sich ja der Robot während des Schritts verschiebt, d. h. beim Schritt nach vorne ist der Schwerpunkt auch weiter vorne und die vorher beschriebene Ideal-Konstellation wieder über den Haufen wirft.

---

Es gibt während der Bewegung keine ideale Konstellation der Gelenkwinkel. Wenn die Beine (mal zufällig) 120° bilden sollten, dann ist dieser Moment auch gleich wieder vorbei.
Du kannst alles zusammen bauen wie Du möchtest, die minimalen Abstände gibt Dir die Mechanik vor, also u.a. Deinen eigene Konstruktion sowie Servogröße. Die maximalen Abstände werden durch die Leistung der Servos/Motoren bestimmt. Diese Erfahrung hast Du ja nun schon angenommen. Je länger das Bein umso mehr Kraft müssen sie haben.
Die Schrittweite hängt von der Konstruktion ab, also der Beinabstand und das damit aufspannende Dreieck. Verlasst der Schwerpunkt das Dreieck kippt der Hexa um. Daher kannst Du mit dem maximalen Beinabstand zwar rechnen, darfst den aber niemals übersteigen. Und die Sicherhietsrechnug darf mit dem Sicherheitswert diese Grenze auch nicht übersteigen. Wenn Du also 15cm Abstand (Fußpunkt-Hüfte) hast, und möchtest 50% Sicherheit erhalten, dann darfst/kannst Du "nur" mit 10cm rechnen bzw das ist der Wert in dem sich später die IK bewegen darf.
Dazu kommt, weil sich ja die Winkel während der Bewegung verschieben, noch die Triangulation am Bein. Also hier dürfen dann die 10cm auch nicht überschritten werden. Allerdings darfst Du auch das Minimum nicht unterschreiten, da Du sonst mit anderen Bauteile kollidierst.

Zitat:

---

Auf alle Fälle hat mir die Rechnung gezeigt, dass der Vorteil durch einen Oktopod nicht mehr so groß ist. Ich sollte wohl direkt die Schulter-Servos stark auslegen.

---

Nur um Verwirrung entgegen zu wirken: Der erste Servo ist der Hüftservo, dann kommt der Oberschenkelservo - diese bilden zusammen die Hüftservoeinheit. Dann kommt der Unterschenkel- (oder Knie-) Servo. Da wir ja eigentlich von Beinen sprechen ist es (für mich jedenfalls) immer gut verwirrend wenn auf einmal etwas von Schulter geschrieben wird...und welchen davon meint man nun.

Zitat:

---

Servo in den Oberschenkel - das ist bei der Konstruktion durch das Gegenlager und damit 2 Platten nicht möglich. (Außer, die Gabel verjüngt sich wieder zu einer Platte, aber dann ist die Servoplatte für den Unterschenkel nicht in der Mitte, ...usw.) Allerdings ist diese Stellung normalerweise noch besser, da so noch mehr Gewicht näher am Körper ist.

---

Doch ist möglich. Du kannst den Unterschenkelservo in den Oberschenkel integrieren indem Du den Oberschenkel halbierst.
Der Hüftservospline und der Fußpunkt sollten auf einer Achse liegen. Der ganze Rest dazwischen kann theoretisch bis nach Rom gebaut werden. Du kannst also theoretisch innerhalb der Breite von den beiden Oberschenkeln den Fußpunkt verschieben - mit der Hüftservoachse.
Deswegen hatte ich vorgeschlagen den Unterschenkelservo in den Unterschenkel einzubauen, dann bräuchtest Du nur den Unterschenkel ändern.
Aber ich meinte auch gesehen zu haben das dort ja auch dein Fußsensor drin ist...

Wie gesagt, wegen dem Fuß klappt diese Art der Konstruktion bei mir nicht so richtig - zumal ich die Lösung so eigentlich ganz gut finde. Einziger Nachteil ist das Kabel, welches ich über das Knie-Servo führen muss, aber da läuft ohnehin ein Kabel drüber, das vom Drucksensor. Der Fuß sieht aufgeschnitten so aus:
Bild hier  
Von unten: Das Gelbe Teil hat oben auf der Säule ein kleines Gummiplättchen. Darüber sitzt der Drucksensor - der sitzt in der superflachen Ritze zwischen grünem und rosa Teil. Das gelbe Teil ist im grünen um 1.5mm beweglich. Es wird aber durch das Gummi immer auseinander gedrückt. (Ganz leicht.) Setzt das Bein auf, wird der Druck auf den Drucksensor konzentriert. Durch die Mechanik ist es fast egal, ob der Fuß in der Mitte oder außen aufsetzt.

Das pinke Teil wird oben durch das blaue Teil geführt. Dann gibt es 4 Pinne die nach unten in das pinke Teil ragen. Links kann man eins davon sehen. Da muss man sich jetzt noch eine Feder hin denken. Man kann zwischen 1-4 Feder im Fuß einbauen, je nachdem wie weich er aufsetzen soll. Der Fuß kann einen guten cm federn.

Die Gummis (oder Federn) wollte ich gemäß Geistesblitz' Idee aufbauen, nur dazu hätten die Gummis außen angebracht werden müssen und die ohnehin breiten Beine noch breiter gemacht und die Beweglichkeit eingeschränkt. Der Effekt ist in leichter Form allerdings auch so vorhanden.

Bild hier  

...wie ich gerade feststelle, fehlen noch die Aussparungen in den Seitenteilen - die kommen noch. :-)

Okay, vielen Dank. Es ist natürlich kein Problem den Servo so zu lassen, denn nur allein um vielleicht einige Gramm Gewicht hier zu sparen alles über den haufen zu werfen ist nicht nötig.

Aber ich sehe jetzt ein neues Problem: Und zwar der Drucksensor in Kombination mit dieser Federung. Wenn Du das so baust, dann benötigst Du in der Federung einen Sensor der die Einfederung messen kann. Der Drucksensor kann das nicht - es sei denn Du bekommmst diese beiden Dinge in Beziehung gesetzt. ich wüßte nicht wie und könnte es demanch nicht.
Das Problem setzt sich in der inversen Kinematik fort - dort bekommst du je nach Einfederung andere Längen im Unterschenkel. Das könnte später ein riesen Problem sein, um den Roboter stabil laufen zu lassen.

Mein Vorschlag dazu: Nimm die Federung raus - oder fixiere sie zu mindest vorerst. Ein oder zwei Stifte durch beide oberen Teile (Stange im Zylinder) sollte dazu genügen.

Viele Grüße

Die Federung kann man als Stoßdämpfer bezeichnen. Die soll auf alle Fälle so stark sein, dass sie nur beim Kontakt mit dem Boden den Stoß abfängt und sich dann wieder auseinander drückt.
Am Drucksensor messe ich bei Bodenkontakt nur einen plötzlichen Anstieg des Drucks, mehr ist nicht nötig. Für genaue Messungen sollte der Bot still stehen.

Dämpft da der Gummifuß nicht schon genug?
Sehe da nämlich auch das Problem, dass dein Stoßdämpfer zu sehr eindrücken könnte und da das überhaupt nicht gemessen wird, weiß der Roboter auch nix davon. Es gäbe ja auch die Möglichkeit, über die Einfederung auf die Fußkraft zu schließen, aber bei beiden Möglichkeiten hast du das Problem, dass der Wert, den du bekommst, wom Winkel des Unterschenkels abhängt. Wenn jetzt mal ganz übertrieben gesagt zum Beispiel der Unterschenkel ganz waagerecht auf der Unterlage stehen würde, würde der Drucksensor gar nix messen, wenn er im 45°-Winkel steht misst er nur noch das 1/wurzel(2)-fache vom tatsächlichen Wert usw. Müsste also in der Software berücksichtigt werden.

Wenn die Gummis/Federn so angebracht sind, bringt es glaub ich auch nicht mehr viel, da kannst die gleich weglassen...

Noch ne andere Sache, vielleicht hab ich es auch einfach übersehen: Wie verhinderst du, dass der Fuß einfach aus dem Unterschenkel rausrutscht?

Da ich ein Bein mit Fuß ja schon (in x Versuchen) gebaut habe, kann ich auch sagen, dass alles funktioniert. :-)
Das "Gummiteil" am Fuß ist kein Gummi und völlig starr. Der Unterschied zum weißen Material ist, dass es nicht rutscht und sich durch die Noppen geschätzt vielleicht einen Viertel Millimeter eindrückt.
Die Federung ist vermutlich nach einer geschätzten 10tel Sekunde wieder auseinander gedrückt.
Zum Druck hab ich schon gesagt, dass ich beim Laufen nur den plötzlichen Anstieg des Drucks messen werde. Für eine vernünftige Messung muss der Bot natürlich nicht nur still stehen, sondern auch seine Füße senkrecht stellen. - Aber ich hatte auch nicht vor, ihn als Haushaltswaage zu misbrauchen. :-p

Achso - zum rausrutschen: Da ist ein Schnappverschluss rechts und links. Einen sieht man auf dem letzten Rendering.

Bein Update:
Bild hier  
Die Formteile um den Fuß werden 3 Schalter, die eine Kollision messen können.

Langsam geht es weiter - die Details machen ja immer mehr Arbeit als der Rest. :-)
Bild hier  
Zu sehen sind die Kupferkabel, die die Kontakte auslösen, wenn der Fuß irgendwo kollidiert. (Ich hab mir jetzt mal gespart, die Kabel in 3D zu verlöten ;-) ) Es gibt 4 von diesen "Platten", wobei die zum Körper gewandte Platte fix am Fuß ist. Die anderen haben die Leitungen, die jeweilt bei Kollision einen Kontakt auslösen. Durch verschiedene Widerstände (Spannungsteiler) kann man an Hand der Spannung auslesen, welcher der Platten Kontakt haben.

Ansonsten werde ich jetzt vom Beaglebone zu diesem Vertreter schwenken: http://www.wandboard.org/index.php/details
Die Platine mit dem Quad verwendet nahezu die gleiche CPU, die auch im HTC One X verbaut ist. (Da ist noch ein 5. Kern für den Stromsparmodus draufgepappt.) Und da man mit Phyton auch mehrere Kerne ansprechen kann, ist das Teil in meinen Augen ideal.

Ich kann mir ehrlich gesagt gerade nicht vorstellen, wie man den Widerstand einbauen kann ohne die Anschlussdrähte zu verbiegen.

Deswegen sind ja die Halter weiter entfernt, als der Widerstand groß ist. Die Drähte müssen danach ja nicht 1a gerade bleiben.

Ja schon, aber warum so kompliziert? Ich meine, wenn ich es recht verstehe, dann wird der Widerstand an den Kupferdraht gelötet oder? In dem Fall würde ich mir die untere Öse für den Widerstand sparen und diese nur oben durch die Führungsöse fädeln. Da er unten an den Kupferdraht (der ja auch in einer Öse geführt wird) gelötet wird, ist er fixiert. Das ganze funktioniert nun ohne lästiges einfädeln o.ä. Verlöten muss man es natürlich immer im aufgebauten Zustand und riskieren, dass das Plastik schmilzt.

Das ist mir zu wackelig. Wenn man oberhalb der oberen Öse rumwackelt, wackelt der Rest ggfs.mit. Da kommen ja ne Menge Kabel und Widerstände zusammen, die oben irgendwo in den Fuß müssen und die ich so nicht dargestellt habe. Das ist dann später wie Mikado spielen, wenn man es zu wackelig aufbaut....

Ansonsten sind an den Stellen, wo man löten muss, entsprechende Aussparungen, so dass der Kunsstoff immer etwas entfernt ist. Man muss dann möglicherweise noch mit Zangen arbeiten, die die Hitze ab einer bestimmten Position ableiten, bevor der Draht wieder in den Kunsstoff ragt.

Na wenn du meinst, ich bin mir zwar ziemlich sicher, dass da nix wackelt, aber jeder darf die Erfahrung machen, dass CAD leicht zu konstruieren ist und real fummelig zu montieren.

Zum Board: Absoluter Overkill, braucht kein Mensch soviel Leistung für so ein System. Abgesehen davon ist es leichter mit µC Hardwarenahe zu programmieren. Wenn es schon ein Board sein soll und kein µC (was ich nicht weiter verstehen muss), dann würde ich wohl wirklich auf ein embedded Board setzen. Da gibt es Mittlerweile eine so große Auswahl an Lösungen, dass es auch schon sehr leistungsfähige Boards mit niedrigem Stromverbrauch gibt. Das Quad braucht 10Watt, da gibt es genug Embedded Boards die mit 1 bis 2Watt auskommen. Die Laufzeit des Hexas würde mit einem niedrigeren Verbrauch signifikant gesteigert werden. Ganz abgesehen davon, dass ein kleineres Board auch viel weniger wiegt.

Ich war fast sicher, dass eine solche Antwort kommt... :rolleyes:

Bevor ich hier eine Diskussion anzettel - gibt es ein paar Beispiele, wo einer eurer n-Pods zügig umher läuft (so schnell, wie es die Servos erlauben), Hindernissen ausweicht, etc.
Ich finde auf YouTube meist nur kleine Test-Läufe, ruckelige, oder sehr langsame Robots.

Zitat:

---

...
Ja, richtig gibt es ein paar Beispiele, wo einer eurer n-Pods zügig umher läuft (so schnell, wie es die Servos erlauben), Hindernissen ausweicht, etc.
Ich finde auf YouTube meist nur kleine Test-Läufe, ruckelige, oder sehr langsame Robots.

---

Ja, richtig...und vermutlich wird sich Deiner sehr bald dazu gesellen. Du wirst schon noch früh genug feststellen das Du keinen Rennwagen baust und DEIN Werk nicht mit maximal Geschwindigkeit an die Wand fahren willst.

Mir ist klar, dass es keine Rennwagen sind, aber sowas ist doch bereits möglich, wenn auch in einem kommerziellen Produkt:
http://youtu.be/-vVblGlIMgw

Dass man am Anfang alles superlangsam laufen lässt, solange man die Software entwickelt und testet ist klar, aber irgendwann sollte man doch diese Bremse einmal lösen.
Mir geht es bei meiner Frage darum, zu sehen, was mit µC möglich ist.

Ich habe mich damals für eine Hybridversion entschieden: die Motore werden von einem Microcontroller gesteuert, damit sie sich genau an den Heartbeat von 100/s halten. Steuercomputer war einfach ein Smartphone über RS232. So musste der Steuerrechner kein RTOS haben und wurde nicht vom Timing laufend unterbrochen. Die RS232-Befehle waren dann recht simpel. Heute würde ich natürlich USB verwenden - oder sogar Bluetooth, dann kann man auch mal nur die Mechanik vom PC kontrollieren.

Ruckeln und langsam ist keine Funktion der Prozessorleistung! Viel mehr eine Frage der Programmierung und der Mathematik die dort implementiert wurde. Meine ersten Hexas liefen sehr ruckelig und langsam und mit jeder Version werden sie "geschmeidiger".
Die Geschwindigkeit hängt von den Servos ab bzw. der Stellgeschwindigkeit. Mit Modellbauservos geht nicht viel mehr als 20ms pro Richtungsänderung.

Matt Denton hat da eigentlich gezeigt was mit Modellbauservos möglich ist.
https://www.youtube.com/watch?v=quN3...aW_5n2A0Wk--57

Die PhantomX hexas sind dann in Sachen Geschwindigkeit sehr beeindruckend schnell:
https://www.youtube.com/watch?v=lnCOLP33Te0

Die PhantomX Teile sind ja beeindruckend!

Ich gebe dir auch Recht, dass das Quadcore-Board oversized ist. Allerdings bin ich (zumindest momentan) noch zu doof um C zu programmieren und möchte es über Python realisieren, was als Interpretersprache natürlich Performance schluckt. Zum anderen denke ich, dass man es über ein komplettes Betriebssystem leichter hat, den Bot mit anderen Rechnern anzubinden. Alles ist auch sicher mit µCs möglich, aber sicher nicht so komfortabel = schnell umgesetzt.
"Ruckeln und langsam ist keine Funktion der Prozessorleistung!" -> Schon, aber weiche Abläufe sind mathematisch komplexer -> geht auf die Performance, genau so wie öfter die Sensoren auslesen und auswerten. Öfter Auslesen -> man kann den Bot vermutlich schneller laufen lassen, weil Kollisionen schneller erkannt werden.

Und falls sich rausstellt, dass sich mein Quad furchtbar langweilt, kann ich ja auch wieder zurück aufs Beaglebone schwenken. :-)

Ich dachte mehr an ein kleines embedded Linux Board, z.b. das Himbeerdings. Allerdings muss ich gestehen, dass ich mit Linux persönlich nicht zurecht komme, ein paar mal habe ich schon den Umstieg versucht, aber bisher hat es nie geklappt. Auf denen läuft dann auch Python! Ansonsten würde ich sagen, dass es eine Frage der Reichweite der Sensoren ist. Bei 5m Reichweite, kann ich den Sensor auch bequem nur alle paar Meter auslesen. Hexas sind in der Regel nicht so schnell, dass sie mehrere Meter in der Sekunde überbrücken. Klar, wenn die Sensoren nur 10cm Reichweite haben wird es Probleme geben, aber wer verwendet schon solche Sensoren?


Mein Vinculum hat einen 8 Core µC bekommen mit 80MHz, damit lässt sich schon einiges machen, die Servos limitieren dann als nächstes die "geschmeidigen Bewegungen"

Ich dachte auch eher an die Druck- und Kollisions-Sensoren der Füße. Das Teil soll ja durch unebenes Gelände und muss merken, wann der Boden da ist.

So, das "Wandboard" hat mich doch etwas länger aufgehalten, weil ich ja auch kein Linux-Crack bin. LAN + WLAN mit automatisch verbinden ist nicht so einfach, wenn man bei Ubuntu den Klickibunti X-Desktop deinstallieren muss...

Das Hexabein ist erst mal fertig und in der ersten Version bei shapeways in Bearbeitung. Die Details zu modellieren dauert dann doch immer etwas länger...
Das Ergebnis: Vom alten großen Spiderbein aufs kleine Hexabein gibt es eine kräftige Gewichtsersparnis bzgl. der 3D-Teile. Alt = 217g, neu = 123g (Ebenso hat sich der Preis von EUR 155 auf EUR 97 reduziert.)

Auf verschraubbare Teile hab ich diesmal verzichtet - alles was "angebaut" werden muss, wird mit Schnapp-Mechanismus realisiert. Jetzt heißt es erst mal ca. 3 Wochen abwarten...

Bild hier  

Bild hier  

Das nächste Bild zeigt, wie der Kram zu shapeways geht. Dort gibt es kräftig Rabatt, wenn das Material mehr als 10% vom Gesamtvolumen ausmacht.
Bild hier