Mein Hexapod-Roboter
günstiger Hexapod, im Selbstbau
Hallo und guten Morgen!
Heute habe ich mich entschlossen, meinen selbst gebauten Hexpod vorzustellen.
Woher die Anregung kam, auch mal so ein Teil zu bauen, können sich die Stammuser hier sicher vorstellen.
Es gab ab und zu Anfragen zu Selbstbauten, von Außenstehenden, die hier im Forum auf Hilfe hoffen.
Nur ohne so etwas jemals gebaut zu haben, kann man immer schlecht Ratschläge erteilen.
Also habe ich mich dran gesetzt, einen möglichst minimalistischen Roboter dieser Art selber zu bauen.
Die Vorlagen, die es für den 3D-Drucker im Netz gibt, habe ich mir angeschaut - vielleicht nicht alle,
das ist wohl sicher. Aber aufgrund dessen, was es so gibt, habe ich mir dann selbst meine Teile entworfen.
Das dauerte dann auch gar nicht so lange. Es ist durchaus erträglich. Drei Tage Teile entwerfen,
mit Probedrucken und noch etwas Feinschliff.
Ich fasse einmal die Daten, für den 3D-Druck, zusammen:
Dazu kommen Kosten für Strom, den der Drucker benötigt.
Filament: PLA Verbrauch: ~250g ohne Fehldrucke ~500g (1/2 Rolle) mit Fehldrucken Materialkosten: 5€ bis 13€ Druckzeit: ~ 3 bis 5 Tage Drucker: Anet A8
Die Druckzeit hängt vom Drucker und den Einstellungen ab.
Zeitweise habe ich, bei größeren Flächen und einfachen geometrischen Formen,
mit doppelter oder dreifacher Geschwindigkeit gedruckt.
An Kleinmaterial habe ich genutzt, was ich da hatte. Drei Sorten Schrauben, etwas Kabelummantelung,
die vom 3D-Drucker-Zusammenbau übrig war, Kabelbinder und kleine Stücken Zahnriemen, für die Füße.
Ich habe im Anhang ein ZIP-File dabei getan. Wer das gerne selbst drucken möchte, findet darin die STL-Dateien. Ich verwende Cura, als Slicer und habe deshalb Bilder mit dazu gepackt, wie die Orientierung auf dem Druckbett aussehen soll, damit die Teile einwandfrei gedruckt werden können. Die Druckereinstellungen muss jeder selbst für seinen 3D-Drucker wählen. X- und Y-Achse des Druckers sollen so kalibriert sein, das möglichst runde Kreise gedruckt werden können. Geringe Abweichungen sind nicht so schlimm, deswegen sollten die Teile dennoch funktionieren. Wie der Platz im Body genutzt wird, bleibt jedem selber überlassen. Im obersten Teil habe ich Platz für ein nodeMCU 1.0 ESP-12E eingeplant; auch so, dass Steckverbinder hindurch geführt werden können. Als Schrauben verwende ich M3*10 und M3*20. Die Teile, die an den Servos befestigt werden sollen (mit den beim Servo dabei liegenden Schrauben) sind mit einem 2mm-Bohrer aufzubohren. Das ist einfach und kein Problem. Teile und Schraubenlänge und -durchmesser sind aufeinander abgestimmt.
Zusammengebaut sieht der Roboter, Gewicht: 650 Gramm (inkl. Akkugewicht) , dann so aus:
Um mich mit dem Thema "Servo" vertraut zu machen und zu sehen, was die Gekauften so können, bzw. wie sie sich verhalten,
habe ich mir zwischenzeitlich einen kleinen Servotester zusammengesetzt:
Bild hier
Dort konnte ich die Pulslänge über Potentiometer verändern und auch einen bestimmten Servo auswählen.
An Elektronik verwende ich:
- Arduino UNO R3, für den Servotester
- MMA8452Q, als Lagesensor (zurzeit noch nicht in Verwendung)
- zwei PCA9685-Boards, zur Servoansteuerung
- Spannungsregler für 6 Volt habe ich bestellt, muss schauen, welche davon ich verwende (zurzeit noch eine Powerbank mit 2x USB, die aber zu schwer ist)
- ATmega328P in der Grundschaltung mit 16MHz
- nodeMCU v1.0 ESP-12E
- SG90 Micro Servo, KY66-10 (9 Gramm schwer, 1kg/cm bei ca. 4.8V)
Das nodeMCU habe ich mit dem ATmega328P, per serieller Schnittstelle (RX/TX), verbunden. Den ATmega versorge ich
mit dem nodeMCU-Spannungsregler (3.3V). Die übrige Elektronik ebenfalls.
Der ATmega328P steuert die PCA9685 an. Übernimmt die Koordination aller Servos, über die Zeit mit unterschiedlich
einstellbaren Verzögerungen (so dass jeder einzelne Servo zu einem andern Zeitpunkt seine Position erreichen kann).
Mit dem nodeMCU schicke ich Steuerpakete an den ATmega.
Um die Stellung der Servos zu programmieren, habe ich für das nodeMCU ein einfaches Interface aufgebaut,
das auf UDP-Paketen basiert, da ich die Software "Packet Sender" schon installiert hatte. Diese Software eignet sich
sehr gut als Ergänzung, weil man damit UDP-Pakete erstellen, speichern, versenden und empfangen kann. Damit programmiere
ich den Hexapod, was eine frickelige Sache ist, aber insgesamt gut funktioniert. So lernt man auch etwas über
die Bewegungsabläufe und ich kann sie Stück um Stück durchgehen und hinterlegen.
Auch wenn die Servos zu den günstigsten Teilen gehören, ist es doch so, dass sie insgesamt Kraft genug haben,
um den Hexapod zu bewegen. Es ist zwar etwas knapp, von der Leistung her, aber nicht unmöglich. Und noch sind
nicht alle Trümpfe (tauglichere Spannungsversorgung) ausgespielt.
Das Zusammenbauen ist schnell erledigt, wenn die Druckteile passend sind. Ich habe bei meinen drauf geachtet,
dass im unteren Teil des Body ein Arduino UNO, als auch ein Mega2560 Platz finden. Es ist damit auch genügend Platz,
für andere Platinen.
...Ich habe für meine Zwecke einen Platinenträger gedruckt, der anstelle eines Mega2560 dort hineinpasst.
Darauf habe ich die PCA9685-Boards verschraubt und meine handgelötete ATmega328P-Platine,
zum Herausnehmen, untergebracht.
Am längsten dauert es, die Software zu schreiben. Dafür gehen einige Tage ins Land. Da ich keinerlei Erfahrung mit so einem Roboter habe,
dauert auch das Erstellen der Bewegungsabläufe seine Zeit. Durch Ausprobieren muss ich mich herantasten, welche Bewegungen wann, wie und
wo eingesetzt werden können und überhaupt funktionieren, dabei immer auch den Strombedarf der Servos im Auge behaltend. Wenn man
alle 18 Stück zusammen ansteuert, bricht gerne mal die Spannung meiner Powerbank ein. Da ich noch keine extra Spannungsregler habe,
habe ich auch noch keinen LiPo angeschlossen, der die Leistung wegstecken würde. Ich würde auch gerne drauf verzichten, mehr als 2000mA
zu benötigen, was aber unmöglich scheint (Erklärung gleich). Hier käme es auf die Bewegungsabläufe an, die dann entsprechend gestaltet sein
müssen, dass maximal 8 bis 10 Servos in Bewegung gebracht werden. Zu bedenken ist, dass die übrigen Motoren noch die Stellung halten müssen,
da braucht's auch ein paar mA.
Die 2000mA werden allein schon erreicht, wenn alle Servos ihre Position halten. Ausgehend von 100mA, sind das bei
18 Stück schon 1800mA. Während Bewegungsphasen steigt der Bedarf weiter an. In Positionen, wo wenig Kraft durch die Motoren aufgebracht
werden muss, um die Position zu halten, kann der Strombedarf eines Servos wesentlich niedriger sein. In Situationen, wo gegen ein größeres
Gewicht angearbeitet werden muss, kann der Strombedarf beim Halten auch größer sein (200mA ... 400mA ... 600mA ... 800mA). Deshalb
schaffe ich es auch nicht, wenn der Hexapod den Body anheben soll, alle 18 Servos aktiv zu haben, ohne dass die 2000mA überschritten werden,
die meine Li-Ion-Powerbank liefern kann.
Was noch geplant ist:
- HY-SRF05 Ultraschall-Sensor-Modul am Kopfservo
- Spannungsregler, an LiPo-Akku, mit einer Strombelastbarkeit bis 5A, für eine stabilere Versorgung
- lichtempfindliche Widerstände (min. 1 Stück)
- Überwachung des Akku-Ladezustands
- Auswerten der Werte des Accelerometers
Fortschritte
Hierunter werde ich mein Vorankommen etwas dokumentieren, damit man einen Überblick über einzelne Stationen der Entwicklung bekommt.
Außerdem ist dann zu erkennen, welche Probleme auftreten, die im Verlauf gelöst werden sollten.
11.05.2019
Nachdem ich angefangen habe, zunächst nur die Servos zu steuern, sind weitere nützliche Dinge hinzu gekommen:
Ein Setup für die Motoren, um die physikalischen Portnummern, an denen die Servos angeschlossen sind, logischen Nummern zuzuordnen.
Da einige Servos entgegengesetzt laufen, kann im Setup die Drehrichtung, für die Befehle "negative." und "positive." umgekehrt werden.
Diese Befehle dienen dem einfachen Verstellen der Servos in eine Richtung, vergleichbar mit "rauf" oder "runter", "vor" oder "zurück".
Aufgrund des Setups ist es nun wesentlich einfacher, einzelne Bewegungssequenzen einzustellen, es geht wesentlich schneller von der Hand.
Stapelverarbeitung für Steuerblöcke:
Bisher konnten in einem Steuerblock zusammengeführte Servos nur parallel gesteuert werden. Jetzt ist es möglich hier die Art
der Steuerung zu ändern, zwischen parallel (alle Servos zur selben Zeit ansteuern) und seriell (alle Servos im Block nacheinander ansteuern).
Hinzu gekommen ist auch ein zweiter Stapel zur Verabeitung, auf dem einzelne Steuerblöcke (jeder Block kann Daten für bis 18 Servos enthalten)
abgelegt werden. Damit sind umfangreichere Bewegungssequenzen an einem Stück möglich.
12.05.2019
Ich habe die Tage schon viel herumgespielt. Ich bin aber inzwischen so weit, den Roboter sich anheben zu lassen. Ausgangsstellung ist
auf dem Boden liegend, Bauch auf der Erde, Beine angezogen. In einigen Schritten passe ich die Beinstellungen an, um ein möglichst
einwandfreies Anheben der 650g Gewicht zu ermöglichen. Da die Mini-Servos nicht wirklich viel Kraft haben, ist das nicht so einfach.
Außerdem habe ich mehrere Versuche hinter mir, wo der Roboter umkippt, wenn er ein Bein anhebt. Hier muss ich noch üben.
(Ab Sekunde 40 geht es richtig los, zuvor nimmt der Roboter eine Grundstellung ein.
Die Servos sind in den Bewegungen verzögert. Was im Video zu sehen ist, entspricht
etwa einer mittleren Geschwindigkeit. Es geht daher etwa noch halb so schnell und
doppelt so schnell.)
14.05.2019
Relative Positionierung ergänzt. Damit können Bewegungsmuster programmiert werden, die immer bezogen auf die letzten Positionen
stattfinden.
15.05.2019
Heute habe ich vier LR20 D Mono - Zellen in Reihe geschaltet und damit den Roboter gespeist. Also die Servos. Mich hat interessiert,
was bei ausreichender Versorgung mit Strom bei ~6 Volt passiert.
Der Hexapod bewegt sich damit wesentlich besser. Er zittert nicht, wackelt nicht. Erreicht seine Positionen an den Servos und stemmt
mehr Gewicht, als ich je erwartet hätte. Meine Versuche mit 950g Gesamtgewicht bewältigt er einwandfrei.
Aber auch dieser Batterietyp liefert nicht ausreichend Strom, der zeitweise benötigt wird. Die Spannung bricht unter Volllast, von
5.66V auf ~3.5V ein.
15.05.2019
Heute habe ich vier LR20 D Mono - Zellen in Reihe geschaltet und damit den Roboter gespeist. Also die Servos. Mich hat interessiert,
was bei ausreichender Versorgung mit Strom bei ~6 Volt passiert.
Der Hexapod bewegt sich damit wesentlich besser. Er zittert nicht, wackelt nicht. Erreicht seine Positionen an den Servos und stemmt
mehr Gewicht, als ich je erwartet hätte. Meine Versuche mit 950g Gesamtgewicht bewältigt er einwandfrei.
Aber auch dieser Batterietyp liefert nicht ausreichend Strom, der zeitweise benötigt wird. Die Spannung bricht unter Volllast, von
5.66V auf ~3.5V ein.
19.05.2019
Ich habe noch mal von vorn angefangen, mich mit Schrittfolgen zu beschäftigen, welche grundsätzlich benötigt werden und wie
der Roboter vorwärts kommen soll. Ich erwähne noch mal, dass ich hier auch absolutes Neuland für mich betreten habe und also
von Grund auf sehen muss, wie alles im Detail zusammenhängt. Mit anderen Konzepten der Steuerung setze ich mich nicht weiter
auseinander, das würde meine Ideenfindung stören.
Ich habe nebenbei schon mitbekommen, dass es über Algorithmen möglich ist, Bewegungen der Servos zu berechnen.
Aber diesem Ansatz der mathematischen Berechnung will ich mich nicht zuwenden. Ich habe es auf erlernbare (programmierbare)
Bewegungsabläufe abgesehen, die dann durch Algorithmen verbessert / korrigiert werden, wenn zusätzliche Sensoren zum Einsatz
kommen. In den letzten beiden Tagen habe ich neue Bewegungsmuster programmiert. Hier gibt es immer mehrere Lösungswege, ein
bestimmtes Problem zu meistern, etwa ein Bein etwas nach außen zu stellen oder Beine anzuheben, damit Servos ihre Endposition
einnehmen können.
Beispiel einer Sequenz
Dieselbe Sequenz für alle Beine
Initialisierung nach Neustart
Bei der Überlegung, ob ich Verzögerungen in den Bewegungen der Servos auch berechnen kann, statt nur auszuprobieren, bin ich
zu der Überzeugung gelangt, dass ich mit meinem Ansatz, zur Programmierung des Roboters, ausreichend zurande kommen sollte.
Denn es werden auch Bewegungen einzelner Beine notwendig, wo alle Servos parallel bewegt werden müssen, aber unterschiedlich
schnell. Ich denke, ich benötige nur die Anfangs- und Endstellung der Motoren, um hier die Werte zu bekommen. Daraus sollte ich
die Verzögerungswerte berechnen können. Es ergibt sich eine Vielzahl an Bewegungssequenzen. Da ich sie für jedes Bein (6 Stück)
einzeln programmiere. Später müssen die Einzelsequenzen noch sinnvoll verknüpft werden, um ein Ziel zu erreichen und sie der
jeweiligen Umgebungssituation anzupassen. Von der Software her bin hier aber noch nicht.
22.05.2019
Die letzten Tage habe ich mich dem Lagesensor (MMA8452Q) gewidmet. Umrechnen der Werte etc.
Ich wollte, dass ein automatischer Ausgleich, über die Beine, in der Horizontalen stattfindet. So dass also eine Schräglage
des Körpers ausgeglichen wird. Dazu habe ich mir die vielleicht einfachste Methode gesucht und erste Versuche unternommen.
Ich lese den Sensor aus und schaue, welche Seite des Roboters nach oben oder nach unten geneigt ist. Auf der gegenüberliegenden
Seite addiere ich zu den Beinen Werte (bspw. +1). Dann werden die Korrekturen an die Servos weiter vermittelt und danach
geschaut, ob die Waagerechte hergestellt ist; wenn nicht, wiederholt sich die Prozedur. Das Prinzip funktioniert. Ich habe aber
festgestellt, dass die richtige Handhabung einen kleinen Rattenschwanz nach sich und durch das gesamte Programm
zieht. Für jeden Motor muss die Position zentral gespeichert werden. Bei jedem Verstellen der Positionen im Programm müssen diese
Positionsspeicher aktualisiert werden. Aufgrund der gespeicherten Positionen kann dann ermittelt werden, ob in eine Richtung überhaupt
noch ein Ausgleich stattfinden kann, ob also ein Bein noch angehoben oder abgesenkt werden kann. Ein Bein, das ständig angehoben wurde,
um eine Schräglage auszugleichen, muss nach Beendigung der Schräglage auch wieder in die Gegenrichtung bewegt werden.
Ein kleiner Anfang in diese Richtung ist gemacht. Aber eine kleine Schräglage macht dem Roboter auch nichts aus. Hier muss ich
etwas drüber schlafen, ob ich das dann weiter verfolge. Ob der Aufwand den zu erwartenden Nutzen rechtfertigt.
27.07.2019
Ich habe viele Teile aus China bekommen, was einige Zeit gedauert hat. Derweil habe ich hier eine Pause gemacht. Ich habe jetzt die Option,
78xx-Spannungsregler (6V), mit Kühlkörpern, einzusetzen. Oder die andere Option, Konvertermodule zu verwenden. Da ich zwei Konverter habe,
stehen damit zweimal bis maximal 5A zur Verfügung. Ich habe 18 Servos für die Beine, einen für den Kopf und das nodeMCU, plus der anderen
(schon genannten) Elektronik. Das sollte sich gut aufteilen lassen auf: 10 Servos und 9 Servos + Elektronik. Ich habe jetzt 4 identische LiPo-Akkus
mit 1000mAh. Nun werde ich zuerst die einfachste Methode versuchen und habe diesen Plan, mit je 2 LiPo-Akkus einen Konverter zu speisen, mit
jedem Konverter jeweils die Hälfte der Verbraucher zu versorgen. Inzwischen habe ich vergrößerte Gehäuseteile hergestellt. Jetzt muss ich einige
Lötarbeiten durchführen, ...
alles umbauen und neu verkabeln.
31.07.2019
Nachdem der Umbau zum neuen Prototyp erfolgt ist, habe ich selbstverständlich auch gehofft, dass nun alles etwas besser
funktionieren würde. Ich habe nun zwei DC-DC-Konverter eingesetzt, die bis 5A Strom liefern können.Nachdem ich diese Konverter verwende, kann ich berichten, dass dies sehr gut funktioniert.
Während bei Betrieb mit normalen Batterien in der Regel die Strombelastbarkeit zu gering ist und die Spannung aufgrund
höherer Belastung zurückgeht, gewährleisten die Konverter einen stabilen Betrieb, bei gleichbleibender Spannung von ca. 6V. Spitzenströme
führen nun nicht mehr zum Ausfall der Elektronik oder der Servos. Zusätzliche Filter, vor oder nach den Konvertern, habe ich nicht verbaut,
das nodeMCU und die übrige Elektronik arbeiten einwandfrei.
Das Gesamtgewicht des Hexapod hat sich, vor allem wegen der nun vier Akkus, auf ungefähr 950g erhöht.
Ich bin mit den 4000mAh in Summe sehr zufrieden. Wenn ich Programmierarbeiten vornehme, kann ich den Hexapod damit
einige Stunden betreiben (1h bis 4h). Bewegt sich der Roboter längere Zeit ständig, verkürzt sich diese Zeit natürlich.
Die Wärmeentwicklung der Konverter hält sich in Grenzen. Kühlkörper sind bis jetzt nicht notwendig, Kleinere können aber noch
nachgerüstet werden (ich habe auch schon welche bestellt). Was im Dauerbetrieb sicher nicht falsch wäre.
Mit der nun besseren Versorgung der Motoren habe ich aber auch zusätzliche Nachteile. Da vorher zu hohe Ströme zum Ausfall der
Spannungsversorgung oder zumindest zum signifikanten Rückgang der Spannung führten, waren die Motoren gut geschützt. Nun sind
mir schon zwei Servos durch übermäßige Wärmeentwicklung bei Belastung (Überlastung) fest gegangen. Das hat natürlich auch mit dem
nun weit höheren Eigengewicht des Roboters zu tun. Offenbar ist das Kunststoffgetriebe betroffen. Die Motoren drehen sich mit Gewalt dann
trotzdem, sie drehen dann aber, bei blockiertem Getriebe, durch. Hier muss ich jetzt, während des Programmierens, noch mehr auf die Temperatur
der Motoren achten. Besonders einseitige Belastungen treten auf, wenn die Bewegungsmuster schrittweise nacheinander programmiert werden.
19.06.2020
Als Abschluss hier eine Bilderstrecke, die ich beim Zusammenbau erstellt habe:
Bild hier
Zahnriemen für die Füße
Bild hier
3 Beine in einem Druck
Bild hier
3mm Löcher nachbohren
Bild hier
vor dem Einsetzen des Motors
Bild hier
Einzelteile zum Zusammenfügen
Bild hier
Servohorn im Druckteil eingesetzt
Bild hier
habe ich nicht benötigt
Bild hier
teilweise zusammengebaut
Bild hier
teilweise zusammengebaut
Bild hier
Motorbefestigung
Bild hier
dto.
Bild hier
letztes Armstück ansetzen
Bild hier
Bild hier
Bild hier
mit Schraube am Servo sichern
Bild hier
Bild hier
Motorbefestigung mit Muttern
Bild hier
anmontierter Arm
MfG
Moppi
Anhang
Befehlsliste für UDP-UI, nodeMCU 1.0 ESP-12E
format.
Formatting the SPIF - file system.
servo.nn,ppp,dd
nn: servo Number 00 - 31
ppp: Position Number 150 - 600
dd: Delay Number 00 - 99 ~Milliseconds
push. / push1.
Moves the last servo position on the stack.
new. / new1.
Cleans the stack.
send.
Sends the stack and play it.
save.nn,name
nn: Number 00 - 99
name: a name of the stack
Saves the stack as number in a array and file.
readdir.
Reads the directory of SPIF - file system.
readstacks.
Reads the names of stacks from the array.
read.nn
nn: Number 00 - 99 in the array of stacks (from stack pointer value 0)
Loads the stack from array.
add.nn
nn: Number 00 - 99 in the array of stacks (from the actual stack pointer value)
update.
Updates the stack in array and file.
positive.nn / positive_.nn
Increments pulse length for servo.
negative.nn / negative_.nn
Decrements pulse length for servo.
get.
Sends servo value as <servo.nn,ppp,dd>
on.
Activates all servos.
off.
Deactivates all servos.
readfile.
Shows a file from directory of SPIF - file system.
setup.ll,pp
ll: logical number for servo, pp: physical servo number (pin/port)
setui.ll,x
ll: logical number for servo, x: 0 - not invert, x: 1 - do invert
chproctype.
Changes stack processing type. From parallel to serial or vice versa.
Zitieren
Lesezeichen