Hexapod – Roboter mit Schüttellähmung

Nachdem nun alle Teile im Haus sind und der Aufbau erst mal fertig ist, geht es daran die Bewegungen richtig in das System zu bekommen. Wie zumeist gibt es auch hier wieder viele Details zu klären und manchmal auch fundamentale Momente von B*******.

Projekt: Hexapod 12 DOF

Kontakt: Boris Dirnfeldner

Link– eigenes Projekt –

Mit den inzwischen angekommenen Schrauben ist die Mechanik schnell fertig aufgebaut und funktioniert auch wie erwartet. Alle Beine haben etwas Spiel, sind aber trotzdem recht gut geführt. Die Servos sitzen sicher und die Elektronik ist provisorisch fixiert. Die Deckplatte habe ich aber nicht festmontiert, da der Kabelbaum von den Servos recht hoch aufträgt und sonst an ein oder zwei Servoarmen scheuern würde. Vorerst aber gut genug.

Mit dem Uno bin ich zunehmend unglücklich. Zwar scheint er noch genug Leistung zu bringen um die Steuerung zu leisten, aber wenn ich dazu Kommandozeilen-Befehle nutze kackt mir das System ab. Nach inzwischen 3 Tagen Versuch und Irrtum, einem komplett neu aufgebauten Modul ohne Fremdcode und viel Frust habe ich davon die Nase voll. Wo immer das Problem ist, es tritt erst auf mit der Kommandozeile, und da finde ich nix mehr. Irgendwo gibt es eine Querwirkung, aber mit der Arduino-Entwicklungsumgebung bekomme ich kaum Hilfe bei der Suche. Perverserweise funktioniert alles auf dem ESP32 ohne Probleme, daher verabschiede ich mich vom Uno früher als geplant. Ohnehin war er schon ziemlich ausgelastet und der Umzug auf den ESP32 auch schon klar, daher spare ich mir die Zeit den Uno hier stabil zu bekommen. Daneben zeigt sich beim Uno auch, dass die Initialisierung des Servocontrollers zu merkwürdigen Ausschlägen bei den Beinen führt. Nicht so beim ESP32. Also weg damit.

Mit den ersten Versuchen und Bewegungen zeigen sich auch Schwächen des gewählten Modells und der ersten Steuerungsversuche. Die verwendeten 9g-Servos sind klein, leicht und billig. Allerdings zeigt sich auch, dass die Mechanik mit der direkten Verbindung an den Servoarm zu Problemen führt. Bei schnellen Bewegungen fährt der Arm wohl über das Ziel hinaus und wird dann recht hart vom Servocontroller zurückgefahren. Dabei geht es dann in die andere Richtung mit dem gleichen Effekt. Im Ergebnis schaukelt sich das dann so stark auf, dass der Robot in Schüttellähmung mit sich selbst beschäftigt ist. Hier mal ein Video wie das dann aussieht:

Eigentlich macht alles was es soll. Da aber die Mechanik ziemlich Spiel hat unterstützt das halt solches Verhalten. Auch die Servos sind hier problematisch, da zwischen den beiden Regelpunkten kaum mechanischer Widerstand vorhanden ist. Das folgende Video zeigt gut das Verhalten im System. Wenn ich mit der Hand das Bein in eine Richtung in den Anschlag führe, drückt der Servo plötzlich dagegen. Das gleiche passiert in die andere Richtung. Im Video sieht man dann ein Ruckeln (wenn der Servo die zentrale Scheibe drückt) und hört den Servo anfahren. Durch den guten Hebel schafft das an sich recht leichte Bein diese Bewegung fast ohne Widerstand, und der starke Servoschub gibt dann Schwung in die Sache. Das lässt sich mit leichtem Anschlagen auch gut provozieren.

Hier muss ich also stärker dämpfen. Am Modell geht das zum einen natürlich durch langsame Bewegungen und durch stärker angezogene Schrauben. Hier wird wohl noch einiges an Try&Error notwendig sein. An den Hebearmen sieht man auch beim Einschalten, das die Servos das Gewicht gut stemmen können. Von der Dimensionierung her passt also alles soweit.

Die Steuerung arbeitet inzwischen auch mit Zwischenschritten zur besseren Kontrolle und auch um langsamere Bewegungen zu ermöglichen. Leider kann ich den Servos keine Stellgeschwindigkeiten vorgeben, daher muss halt die Software ausreichend Zwischenschritte einfügen. Dazu läuft im Hintergrund für jedes Gelenk eine Steuerung, die eine (vorerst) lineare Anpassung der PWM-Stellvorgaben berechnet und derzeit ca. 20-mal pro Sekunde anpasst (mehr konnte der Arduino Uno nicht mehr leisten). Das Servo arbeitet mit ca. 50 Hz, es gibt also noch Luft nach oben. Man hört und sieht auch, dass ein leichtes Ruckeln in den Bewegungen vorhanden ist. In der Software gibt es inzwischen auch Logik, um Bewegungssequenzen aneinander zu reihen und abarbeiten zu lassen. Natürlich nicht optimal, aber fürs erste ok.

Hier ein Video für eine einfache Testsequenz. Man sieht das kontrollierte Bewegungen an den Hebearmen im Vergleich schon gut gelingen.

Bei den ersten Gehversuchen hat sich auch gezeigt, das mit nur 12 Freiheitsgraden das Modell mechanisch zu eingeschränkt ist um flüssig wirkende Bewegungen zu erlauben. Die Beine können so nicht nach Außen oder Innen bewegt werden und rutschen so immer am Boden rum. Verstärkt wird das Verhalten auch durch die Platzierung der Beine, hier wäre es wohl besser eine rechteckige Grundform zu wählen und dann die Beine seitlich zu platzieren. Kommt auf den Merkzettel fürs nächste Modell.

Der Einfachheit halber werden die Servos aktuell mit einem 18650-er Schield von Wemos versorgt. Das ist zwar wegen den integrierten Lade- und Sicherungskomponenten schön, auch wegen des mechanisch kompakten Aufbaus, aber leider scheint die Wahl des 18650 ein Fehler zu sein. Beim Einschalten oder bei schnellen Bewegungen scheint hier die Last zu hoch zu werden und das Modul schaltet die Stromversorgung ab. Zwar meint das Teil bis zu 4A bei 5V liefern zu können (laut Aufdruck), aber richtig glauben will ich das nicht. Der Akku sollte typischerweise mit 1C belastbar sein, also mit bis zu 2,2A. Im Internet wird bei den Servos von ca. 200mA Strom gesprochen, in der Spitze sogar bis zu 600mA im Anschlag (also volle Leistung gegen ein Hindernis). Wenn da mehrere Servos gleichzeitig loslegen, kann ich mir schon eine Überlastung der Versorgung vorstellen. In der Praxis schaltet das Modul dann die Spannung fast komplett weg und benötigt dann einen „Neustart“ per Akku raus und rein. Lästig, aber ok zum Testen. Später muss ich wohl eine richtige Versorgung per Modellbau-Lipo etc. machen.

Fazit:
Es war ja eigentlich schon klar, dass der erste Versuch nicht so richtig gut sein wird. Das Modell sollte primär schnell druckbar und einfach aufgebaut sein. Im Nachhinein ist es zu einfach aufgebaut um wirklich flexibel zu sein, aber trotzdem ein guter Start. Die Probleme mit dem Arduino Uno sind leider auch nicht unerwartet gekommen. Und dass es bei komplexen Bewegungen Zeit benötigt um eine gute Lösung zu schaffen ist auch klar. Wer sowas schon mal angefangen hat, kann dies sicher gut nachvollziehen. Mit dem Modell wird jetzt erst mal weiter geprobt und Software als auch Mechanik zu einer gewissen Reife gebracht. Nächstes Jahr sehe ich aber eine neue Version kommen, dann mit 18 Freiheitsgraden, besseren Servos und auch mehr Hintergrund aus der aktuellen Runde.

Hexapod – Wir werden besser

Der erste Ansatz hat ja einige Probleme mit sich gebracht und leider doch wieder einige Anpassungen notwendig gemacht. Neben der ...

Hexapod – wir lernen laufen

Die Hausspinne hat inzwischen Fortschritte gemacht, genug um den neuen Stand in einem Text zu beschreiben. Verbesserungen im Steuerprogramm, neue ...

Hexapod – Roboter mit Schüttellähmung

Nachdem nun alle Teile im Haus sind und der Aufbau erst mal fertig ist, geht es daran die Bewegungen richtig ...

DIY – Hexapod als neue Hausspinne

Ein schon langes geplantes Projekt, dass ich aber auch lange mangels Zeit verschieben musste, war ein Hexapod aus eigener Fertigung ...

Klimadatenexpress

Heute war mal das Ziel, ein Miniprojekt binnen Tagesfrist durchzuziehen. Ausgewählt habe ich dafür einen kleinen Klimalogger, da mich unsere „Wetterstation“ wegen eines fast unleserlichen Displays fürchterlich nervt. Die Teile sind vorhanden und die erforderliche Software ist auch vorbereitet, wenngleich nicht spezifisch für die Lösung angepasst. Auch will ich wissen, ob die ESP32-Controller die Wetterverhältnisse im Außenbereich aushalten.

Projekt: Logger für Klimadaten

Kontakt: Boris Dirnfeldner

Link– eigenes Projekt –

Ziel:
An sich will ich wissen, wie sich die Controller-Elektronik in den verschiedenen Wetterverhältnissen von Hochsommer und Winter bewährt. In der Solaranlage werkelt ein Raspberry in einem DIN-Gehäuse und macht es sich dort selber warm, sollte also keine Probleme haben.
Der Controller hier dürfte weniger Komfort genießen, zumal er zwingend (bzw. der Sensor) dem Wetter ausgesetzt werden muss. Da ich in anderen Projekten auch mit Wettereinflüssen klarkommen muss, will ich erst mal ein einfaches Minimalsystem austesten.
Unabhängig davon sollen die Werte für andere Projekte verfügbar sein und für mich als Benutzer angezeigt werden.

Konzept:
Es soll eine kleine Einheit im Carport die wichtigsten Klimadaten erfassen (Temperatur, Luftfeuchte und Luftdruck) und per MQTT auf den Hausbus schicken. Eine Loggersoftware soll die Daten kontinuierlich in eine Datenbank wegsichern. Zuletzt soll eine kleine Webseite die aktuellsten Daten visualisieren.
Zeitrahmen für die Lösung ist ein Tag (bzw. eher ein halber da ich den Entschluss unter Tags getroffen habe). Der Sensor soll ein BME280 sein an einem kompakten ESP32 zur Netzwerkanbindung. Der Softwareanteil besteht neben der Controllersoftware aus weiteren Python-Services auf dem Haus-Raspberry. Der MQTT-Server ist schon da, ebenso ein WLAN zur Anbindung. Das Ganze soll in ein einfaches Gehäuse mit guter Durchlüftung. Als Stromversorgung soll ein altes USB-Netzteil mit 5V und Mikro-Stecker herhalten.

Software:
Für den ESP32 ist bereits das meiste als Basislibrary da und in C++/Arduino gelöst. Mit dabei ist ein fertiges Logging, ein Scheduler, Wifi-Anbindung und das rudimentäre MQTT-Handling. Primärer Aufwand ist die Produktausprägung einzuarbeiten, die Libs zu aktualisieren und manche Konfig-Details für das Heimnetz anzupassen. Die Umgebung kann so schnell dazu gebracht werden in einer definierten Zeitspanne den Sensor auszulesen und an den MQTT-Bus zu schicken.

Elektronik:
Der Teil ist eigentlich wirklich einfach. Ein BME280 Breakout-Board muss mit dem ESP Controller per 4 Leitungen verbunden werden (Strom und I2C). Diesmal soll es nicht mit Dupont-Kabeln laufen, sondern eine feste Kabelverbindung. Die Teile nehme ich damit ohne Pins aus dem Vorratsfundus (ungetestet). Da ich löten hasse, dauert es dann doch etwas. Danach Software draufgeladen und Testlauf. Siehe da, wieder mal geht nix, der Sensor wird nicht erkannt. Zum Glück und mit den Erfahrungen der letzten Runden habe ich einen I2C-Scanner als Controller-Software bereit, aber die findet auch nix. Strom bekommt der Sensor laut Multimeter. Vermutlich habe ich also wieder die I2C-Verbindungen verwechselt. Also die beiden Leitungen rausgelötet, mit dem Scanner umgekehrt getestet und siehe da, da taucht ein Gerät auf. Dabei zeigt sich auch, dass die Busadresse eine andere ist als sonst (0x77 statt 0x76). Also nun richtig angelötet und die Software angepasst und plötzlich liefert der Sensor auch Daten. Das Ganze wird in eine Kaugummidose aus Plastik reingepackt, die mit einigen Löchern versehen wurde zur Durchlüftung. Der Sensor ist mit einem Klebepad am Deckel montiert, der ESP klemmt im Gehäuse recht stabil drin. Da das Teil nicht bewegt wird, sollte es so erst mal passen.

Datenbank-Logger:
Der Logger wird einfach aus den anderen Projekten mit Python wiederverwertet. Die entsprechenden MQTT-Themen abonnieren und bei Eingang in getrennte Tabellen eine SQLite-Datenbank schreiben. Das Ganze noch als Service konfiguriert und schon ist das Teil fertig.

Weboberfläche:
Auch hier wird Bestandscode wiederverwertet. Die Oberfläche der Solaranlage stark vereinfacht (nur 3 Anzeigen), zeitbasierte Aktualisierung der Daten aus der Datenbank und schon sehe ich die Werte ansprechend dargestellt im Browser.

Zwischenfazit:
An sich funktioniert das alles. Allerdings fällt auf, dass im Vergleich der Sensor ca. 4°C mehr Temperatur anzeigt als die Wetterstation und ca. 8% mehr Luftfeuchte. Zwar folgen die Werte dem Tagesverlauf und sind auch nicht notwendigerweise gleich (weil der andere Sensor an der Außenseite des Carports hängt), sind aber trotzdem durchwegs und deutlich zu hoch. Nach etwas Recherche haben viele Leute das Problem speziell mit dem Sensor. Dabei gehen die Probleme von schlechten Fälschungen über Fabrikationsfehler hin zu Verfälschungen durch die Wärmeabgabe des ESP und des Sensors selber. Manche trennen Controller und Sensor um bis zu 20cm voneinander, andere arbeiten mit langsamen Lüftern. Da ich einen China-Nachbau habe, kann natürlich alles stimmen oder nichts. Leider fehlt mir auch ein kalibriertes Vergleichsmessgerät, damit muss ich mit der Wetterstation als Vergleich vorerst leben.

Anpassungen:
Eine vom Hersteller (Bosch) genannten Maßnahmen ist die Parametrisierung des Sensors. Anscheinend sollte der Sensor, je nach Einsatzgebiet, mit verschiedenen Parametern zu Filter und Sampling versehen werden. Die für Wettermessung geeigneten Parameter lassen sich leicht anpassen. Damit sollte der Sensor eigentlich besser funktionieren. Um die Wärme des ESP besser zu vermeiden läuft das System erst mal mit geöffnetem Deckel (damit der Sensor im Freien) und für den ESP sind zur Entlüftung noch ein Paar Löcher dazu gekommen (diesmal ins Gehäuse). Damit stimmt die Temperatur nun auf 0,5°C genau überein und ist damit auch gut genug. Die Luftfeuchte passt allerdings immer noch nicht.
Ein Versuch mit einer Trennwand aus Karton zur Abtrennung von ESP und Sensor verschlechtert das Ergebnis wieder. Vermutlich kommt nun wieder weniger Frischluft an den Sensor oder so. Da die Temperatur nun aber gut genug zu sein scheint, lasse ich das Teil erst mal so laufen. Wettertechnisch ist es ausreichend geschützt und für alles andere taugt das „Gehäuse“ ohnehin nicht. Auf Lüfter oder ein gedrucktes Gehäuse verzichte ich erstmal, bis ich hier eine wirkliche Lösung habe. Auch würde es den gesetzten Zeitrahmen überschreiten.

Fazit:
An sich ist es ganz gut gelaufen. Das Konzept funktioniert und die Werte der Temperatur passen so. Damit kann ich ganz gut sehen, ob das Teil so über den Winter kommt oder ob Minusgrade hier zu viel des Guten sind. Ob ich beizeiten noch Korrekturen der Werte, z.B. über Offsets einbaue muss ich die nächsten Tage sehen. Grundsätzlich wäre auch ein neues Gehäuse oder ein anderer Sensor zum Vergleich eine Option. Aber vorerst bleibt es so wie es ist.

Wir benutzen Cookies und Logs mit personenbezogenen Daten ausschließlich für essentielle Funktionen wie z.B. bei der Benutzeranmeldung oder der Fehlersuche. Für Videos werden weitere Cookies von Drittanbietern benötigt. Details finden sie unter dem Link "Weitere Informationen".