Smarte Poolpumpe mit ESPHome und Home Assistant

2024-07 | Projekte

Die Poolpumpe war ja schon öfters Thema hier im Blog. In der neuen Saison wurde nun endlich die Integration ins Hausnetz vorgenommen. Home Assistant und ESPHome haben sich hier ausgezeichnet.

Projekt: Smarte Poolpumpe
Kontakt: Boris Dirnfeldner

Ein wichtiger Schritt in praktisch jeder Automation ist die Integration von Sensoren und Aktoren in die Steuerung. Je nach Umfeld ist das dann mehr oder weniger einfach und mächtig.

Die Umwälzpumpe des Rundpools war bisher durch eine einfache Zeitschaltuhr gesteuert worden, die auf der Klemmschiene mit den Sicherungen am Pool in die Stromversorgung der Pumpe eingeschliffen war. Das Ganze mit wasserdichtem Gehäuse und einem Not-Aus Knopf zum vollständigen Abtrennen der Stromversorgung war das schon in Ordnung. Einfach mal kleine Anpassungen zu machen oder eine komplexere Logik waren aber so nicht drin. Daher war der Wunsch da, die Anbindung an die Haussteuerung zu bekommen.

Man hätte jetzt einfach ein fertiges Modul für ein Paar Euro reinschleifen können und das in den Home Assistant über die Automation anbinden. Allerdings zeigen die bisherigen Erfahrungen, dass die Wifi-Anbindungen zuweilen unzuverlässig sind und (wenn man nicht einfach einen Steckeradapter nehmen kann) auch preislich relevant.

Mit den guten Erfahrungen der letzten Zeit (und mit Blick auf meine Lagerbestände) wurde daher etwas Material einer sinnvollen Anwendung zugeführt. Konkret brauchte es einen ESP32 Controller, ein Relaismodul und ein Netzteil. Für die Montage noch ein Hutschienengehäuse und Kabel.

Die Logik ist mit ESPHome schnell erstellt. Nach den Problemen zuletzt mit Windows ist nun Linux als Entwicklungsumgebung in Anwendung. ESPHome kann auch als Docker-Instanz verwendet werden, da geht es dann schnell eine lauffähige Umgebung zu gestalten (nur Ubuntu und Docker müssen vorhanden sein).

Die Konfiguration in YAML ist trivial und sieht so aus:

esphome:
  name: poolpumpcontrol

esp32:
  board: wemos_d1_mini32
  framework:
    type: arduino

# Enable logging
logger:

# Enable Home Assistant API
api:
  password: "XXX"

ota:
  - platform: esphome
    password: "XXX"

wifi:
  ssid: "XXX"
  password: "XXX"
  domain: ".fritz.box"

# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
  ssid: "Poolpumpcontrol Fallback Hotspot"
  password: "XXX"

captive_portal:

switch:
  - platform: gpio
    pin: GPIO12
    id: "pool_pump"
    name: "Pool Pump"
    icon: "mdi:pump"
    restore_mode: ALWAYS_ON

Um das Ganze auf den ESP32 zu bekommen, braucht es nur den folgenden Befehl:

sudo docker run --rm -v "${PWD}":/config --device=/dev/ttyUSB0 -it ghcr.io/esphome/esphome run poolpumpcontrol.yaml

Danach war der Controller bereit für den Einsatz. Beim Zusammenbau das übliche gefrickel, bis alles zusammenpasst und miteinander arbeitet. Zum Testen wurde erstmal alles offen aufgebaut, bis das System richtig funktioniert hat.


Im Detail war scheinbar das Relais-Modul defekt und wollte keinem Steuerkommando folgen. Nach Austausch war das aber ok. Dabei habe ich noch einen defekten Mikrocontroller gefunden (Wifi wollte da nicht hochkommen). Zumindest reduziert sich so der Elektroschrott im Bestand.


Das Hutschienengehäuse wollte nicht richtig in das Elektrogehäuse passen, da war auch etwas (mechanische) Nacharbeit erforderlich.

Im Home Assistant war das Gerät sofort sichtbar und steht nun für jeden Unsinn offen.

Und dann noch eine entsprechende Visualisierung für den geneigten Benutzer zu bekommen, war dann nur noch eine Fingerübung.

Damit steht ab sofort die Option offen, damit auch wesentlich intelligentere Logik zu nutzen. In nächster Zeit wird wohl die Logik des ESP aufgebohrt, damit er auch gut mit Offline-Zuständen und dem Aus- und Einschalten per Not-Aus umgehen kann. Die Benachrichtigung über Telegram ist schon drin, auch kann ich nun über OTA die Firmware jederzeit per Wifi aktualisieren und die Debug-Meldungen auslesen.

In Summe wieder ein kleiner Schritt vorwärts. Nicht zwingend nötig, aber nett und ohne großen Aufwand.

ESPHome – Home Automation mit ESP32 mal wirklich ganz einfach

2023-05 | Projekte

Mit jedem Tag zeigt sich, dass Home Automation ein sehr mächtiges Werkzeug geworden ist. Im Zuge der Tests bin ich auf ESPHome gestoßen, und jetzt geht es so richtig los.

Projekt: Heimautomatisierung

Kontakt: Boris Dirnfeldner

Link: – eigenes Projekt –

Da ich viel mit ESP32 gearbeitet habe, möchte ich diese Erfahrungen gerne auch in der Hausautomation verwenden. Obwohl es schon viele Teile zu kaufen gibt, sind halt nicht alle Wünsche mit Kaufteilen zu erfüllen oder manchmal dann doch zu teuer. Ein gutes Beispiel sind Helligkeitssensoren, die als Kaufteile mir einfach zu teuer sind. Mit ESPHome fand sich aber eine Lösung, die mir eine sehr einfache Anbindung von solchen Kleinstlösungen erlaubt ohne sich mit den vielen kleinen dafür erforderlichen Schritten beschäftigen zu müssen (wie z.B. Crosscompiler, Apps, Bibliotheken, Fehlerbeseitigung).

https://esphome.io/

Grundsätzlich kann man über mehrere Wege mit ESPHome arbeiten, allerdings sind auch Voraussetzungen zu beachten. Richtig komfortabel wäre die Integration, wenn man Home Assistant im eigenen OS Supervidord am Laufen hat, z.B. am Raspberry. Dann könnte man die Integration von dort laden und komplett über Home Assistant arbeiten.
Ich habe Home Assistant Core unter Docker am Laufen was den Durchgriff auf das drunter liegende Betriebssystem erheblich erschwert, daher funktioniert das so nicht.
Daher bleibt der Weg über die Kommandozeile manuell und später nur das fertige Gerät zu integrieren. 

Installing ESPHome Manually.

Meine Umgebung ist ein Windows 10 PC und Python 3.10 installiert über Windows Store. Auf einem Linux geht das praktisch genauso.
Auf der Kommandozeile kann ich damit die benötigten Packages nachinstallieren.

pip3 install wheel

pip3 install esphome

Anmerkung dazu: Ich würde empfehlen, eine eigene Installation von Python aufzubauen, die Store-Variante ist später eklig im Handling.
z.B. findet sich bei mir nach der Installation das Kommando esphome in C:\Users\User\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.10_qbz5n2kfra8p0\LocalCache\local-packages\Python310\Scripts
Ob alles geklappt hat, kann man einfach mit einem Aufruf prüfen:

esphome version
Version: 2023.05.04

So weit ist also alles gut, nun geht es an das eigentliche „Programm“.

Getting Started with the ESPHome Command Line — ESPHome
Physically Connecting to your Device — ESPHome

Aus einem früheren Projekt hatte ich schon ein fertig aufgebautes System ESP32 (Wemos D1 Mini) mit BME280 Sensor mit einer eigenen Software.
Der hätte für Home Assistant erweitert hätte werden müssen und dann entsprechend einkonfiguriert. Das ist mein Testobjekt oder Opfer.

Um ESPHome auf den ESP zu bekommen, muss zuerst ein geeignetes YAML erstellt werden.
Die Basiskonfiguration kann man leicht über den Wizard vom Kommandozeilentool erstellt bekommen.

esphome wizard test.yaml

Mit der damit erstellen Datei kann man dann die Konfiguration für die Peripherie dazu packen. Bei mir wäre das der I2C Bus (über den der Sensor kommuniziert) und natürlich der Sensor selbst.

BME280 Temperature+Pressure+Humidity Sensor — ESPHome

I²C Bus — ESPHome

esphome:
  name: esphome-00001
 
esp32:
  board: wemos_d1_mini32
  framework:
    type: arduino
 
# Enable logging
logger:
 
# Enable Home Assistant API
api:
  password: „“
 
ota:
  password: „“
 
wifi:
  ssid: „XXX“
  password: „XXX“
 
  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: „Esphome-00001 Fallback Hotspot“
    password: „XXX“
 
captive_portal:
 
# Ergänzung nach Wizard
i2c:
  sda: 21
  scl: 22
  scan: true
  id: bus_a
 
sensor:
  – platform: bme280
    temperature:
      name: „BME280 Temperature“
      oversampling: 16x
    pressure:
      name: „BME280 Pressure“
    humidity:
      name: „BME280 Humidity“
    address: 0x77
    update_interval: 60s

Mit dem nun vorhandenen YAML kann man auf das ESP installieren. Da bei mir kein OTA-Code vorhanden war, musste der ESP am Rechner per USB verbunden werden (Serieller Port vom Typ CCxxxx wird im Gerätemanager angezeigt).

esphome run test.yaml

Damit wird dann im Hintergrund die Firmware zusammengestellt und kompiliert. Die erforderlichen Teile wie Libraries, Compiler etc. holt sich das Programm selbst aus dem Internet. Das war für mich schon komfortabel, weil mich gerade diese Tätigkeiten extrem anöden (zumal sowas ja auch gepflegt werden muss).
Wenn der ESP korrekt im Betriebssystem angemeldet ist (als serieller Port), wird dann vom Skript gefragt, über welchen Weg man die Firmware installieren will. Zur Auswahl steht dann der Port oder OTA. Da der ESP noch kein OTA kann, wird der serielle Port ausgewählt.
Das Tool flasht dann die Firmware, bootet den ESP und zeigt danach die Debug-Meldungen vom ESP als Ausgabe. Wenn was schief geht, kann man es hier mitbekommen.
Ich hatte z.B. das Wifi nicht Case-Sensitiv eingegeben und prompt ging das Anmelden nicht. Kein Problem, weil ich ja unmittelbar über die Meldungen das Problem sehen konnte und ein angepasstes YAML neu drüber installieren lassen.
Wenn alles geklappt hat, ist ab sofort im Heimnetz ein neuer Teilnehmer registriert und aktiv.
Für mich das absolut beste war aber, dass mein ESP gleich vom Home Assistant als neues Gerät erkannt wurde und über die Erweiterung ESPHome direkt eingebunden wurde. Keine weiteren Konfigurationen notwendig, sofort Gerät und 3 Entitäten verfügbar.

Ebenso einfach ist es ab sofort ein Update von der Firmware zu machen. Das geht nun direkt über OTA ohne Kabel per Netzwerk.
Wenn ich die Supervisord-Variante von Home Assistent hätte (nicht die Core-Variante im Docker Container), könnte ich das ganze sogar über die Oberfläche triggern. Mir ist es aber wichtiger so mit Docker weiterzumachen, daher bleibe ich bei der Kommandozeile und der eingeschränkten UI.

 

 

Nachtrag:

Die ganze Geschichte mit den Voraussetzungen schaffen hat mich nun doch nochmal eingeholt. Bei der Umstellung auf ExpressIf als Plattform (wegen Bluetooth) wurde der Pfad-String zu lange und konnte nicht mehr kompiliert werden. Bei der Einzelinstallation von Python ohne AppStore ging das Thema dann.
Danach konnte aber eine Abhängigkeit wegen einer angeblich geblockten Datei nicht aufgelöst werden. Tatsächlich aber auch kein Problem von ESPHome, sondern von ExpressIf selbst. Da scheint es mit 5.x-Versionen Probleme unter Windows zu geben. Mit einem alternativen Paket über GitHub 4.x war dann alles wieder ok.
Es bleibt also immer noch so, dass man sich irgendwann in den Tiefen durchwursteln muss. ESPHome versucht das aber sehr gut zu deckeln, bis halt gar nix mehr geht.
Und wenn es in Drittpaketen knallt, wäre es unfair das ESPHome zuzuordnen.
Ich würde auch stark darauf tippen, dass es unter Linux hier keine Probleme gegeben hätte. Wer kann, sollte vielleicht gleich damit starten. Ich denke das umschifft dann viele Klippen.

https://www.pexels.com/de-de/foto/dunen-des-death-valley-17108927/

Freiheit für Tuya-Geräte von der Cloud

So langsam wächst die Geräteanzahl und einige davon sind von Tuya. Die Zwangscloud ist nicht nur theoretisch ein Problem, sondern ...
Weiterlesen …

ESPHome – Home Automation mit ESP32 mal wirklich ganz einfach

Mit jedem Tag zeigt sich, dass Home Automation ein sehr mächtiges Werkzeug geworden ist. Im Zuge der Tests bin ich ...
Weiterlesen …
https://www.pexels.com/de-de/foto/bunte-zahnrader-171198/

Hausautomatisierung – jetzt aber richtig!

Nach inzwischen doch schon einigen mehr oder weniger erfolglosen Versuchen, das eigene Heim etwas intelligenter zu gestalten, ist nun ein ...
Weiterlesen …

ESP32 funkt mit Blauzahn

2021-01 | Projekte

Bei einer Suchaktion ist mir mein alter PS3-Controller wieder in die Hände gefallen, mit dem ich meinen Buggy gebaut hatte. Damals hatte ich mein Pairing-Problem mit Bluetooth umschifft und stattdessen eine USB-Kabelanbindung verwendet. Mit dem ESP32 hätte ich eigentlich wieder Bluetooth zur Verfügung, daher ist es Zeit wieder einen neuen Versuch zu starten. Auch fürs Debug-Logging wäre es schön, wenn über Bluetooth ohne USB-Kabel gearbeitet werden könnte.

Projekt: ESP32 Bluetooth Basics

Kontakt: Boris Dirnfeldner

Link: – eigenes Projekt –

Ziel:
Es soll für ESP32-basierende Projekte das Bluetooth-Modul verfügbar gemacht werden. Als unmittelbare Features will ich den PS3-Controller per Bluetooth verwenden können und das Debug-Logging über Bluetooth verfügbar machen.

Konzept:
Der ESP32 hat ja eigentlich ein recht ordentliches Bluetooth-Modul eingebaut (bisher ungenutzt). Dafür gibt es bereits fertige Libs, die unter Arduino verwendbar sind und recht einfache Einbindung versprechen.

Debug-Logging:
An sich ist das ein No-Brainer. Die Lib einbinden (ESPSoftwareSerial), eine Instanz erzeugen und wie Serial als Ausgabe nutzen. Das Teil hat lediglich einen beachtlichen Speicherhunger, so dass die Standardeinstellungen zum Partition-Schema nicht mehr nutzbar sind. Wenn man der App aber mehr Platz zugesteht (Huge App/ 3MB) dann ist das wirklich so einfach. Ob die Lib so riesig ist oder Bluetooth einfach den Platz braucht habe ich nicht nachgeprüft, da ich ohnehin früher oder später auf diese Konfiguration hätte wechseln müssen und das Interesse daran erst mal eher akademisch ist. Das Ganze habe ich auch gut in meine Basisumgebung integrieren können, so dass ich das für alle ESP-basierenden Programme gut verwenden kann. Der ESP meldet sich als Bluetooth-Serial-Gerät und kann z.B. am Handy per App (z.B. Serial Bluetooth Terminal) als Debug-Hilfe ohne bauliche Änderung verwendet werden. Bei manchen schnellen Tests hätte ich mir das schon viel früher gewünscht.

PS3 Bluetooth Controller:
Der Controller liegt bei mir schon länger rum. Ursprünglich hatte ich damit meinen Buggy gelenkt, allerdings kabelgebunden. Da mein Hexapod auch wieder einen Controller nutzt (PS2 mit Funkdongle) und Probleme macht (Funkdongle hat manchmal Verbindungsverluste und ist groß) wäre eine reine Funklösung schon schön. Auch hat der PS2-Controller auf den Analog-Sticks deutliche Totpunkte, die am PS3-Controller weniger ausgeprägt waren.
Auch hier gibt es bereits ordentliche Libs, wobei ich mich für ESP32-PS3 entschieden habe. Von der Anbindung auch einfach und mit den Beispiel-Programmen auch toll dokumentiert. Und es hat mir endlich erklärt warum ich damals damit nicht weitergekommen bin. Die Playstation-Controller verbinden sich nicht wie ein normales Bluetooth-Gerät, sondern verlangen ein kabelgebundenes Pairing und akzeptieren dann auch nur Verbindung mit der dabei übergebenen MAC-Adresse. Zum Glück findet sich ein entsprechendes Tool für diesen Vorgang (SixaxisPairTool). Damit kann ich sowohl die aktuelle MAC auslesen oder auch neu setzen. Und damit funktioniert auch die Anbindung an den ESP32 schon fast zu einfach. Das Beispielprogramm zeigt mir, das ich auf alles Knöpfe und Knüppel Zugriff habe und auch die Spieler-ID korrekt setzen kann. Akkustand gibt es auch gemeldet, lediglich der Lage- oder Beschleunigungssensor scheint nix zu liefern. Ob der Controller überhaupt einen hat weiß ich aber auch nicht. Das Teil wird auf jeden Fall auch in meine Basis-Library integriert, dann kann auch mein Hexapod ab sofort auch ohne Dongle arbeiten.

Fazit:
Bluetooth war ein wichtiger Schritt vorwärts, zumal der ESP32 bei mir derzeit das Mittel für praktisch alle Projekte ist (wenn es kein Raspberry oder mehr sein muss). Es gibt hier schon recht ordentliche Lösungen die auch recht einfach gehalten sind, gerade weil die ESP-eigene Umgebung doch recht komplex ist (wenn auch leistungsfähiger). Ich schätze es aber, wenn ich durch das Arduino-Konzept einfach Zeit und Mühen spare. Und derzeit gibt es keine zwingenden Gründe hier eine Umstellung zu machen.
BTW: Bei der Gelegenheit habe ich mir noch einen PS4-Controller bestellt. In der Theorie geht der auch, hat aber zusätzlich ein Touchpad und eine Mono-Soundausgabe. Ob das klappt ist aber ein eigenes Mini-Projekt und Thema eines anderen Artikels.

To be continued…. 

Hexapod – Wir werden besser

2020-11 | Projekte

Der erste Ansatz hat ja einige Probleme mit sich gebracht und leider doch wieder einige Anpassungen notwendig gemacht. Neben der Schüttellähmung bei den Drehservos ist leider auch immer wieder die Servoansteuerung ganz ausgestiegen und die Bewegung wurde nie flüssig. Inzwischen sind wir hier weiter und ein neuer Artikel ist fällig.

Projekt: Hexapod 12 DOF

Kontakt: Boris Dirnfeldner

Link: – eigenes Projekt –

Nachdem die Software eine gewisse Reife hatte, sind trotzdem einige Dinge nicht durch simples Parametertunen zu lösen gewesen.

Das große Zittern
Ein wirklich blödes Verhalten war das ständige Gezittere bei den Drehservos. Die Plastikgetriebe (ok, Nylon) sind zwar ok und sehr günstig, da aber dann doch überfordert. Nur mit anziehen der Schrauben wurde es zwar etwas besser, am Ende aber immer noch ein Problem oder die Gelenke nicht mehr zu bewegen. Da ich inzwischen Servos mit Metallgetriebe habe (MG90), wurden die 6 Drehservos kurzerhand getauscht. Die MG90 sind hier um Welten besser und bieten kaum Spiel. Damit war das Aufschaukeln weg und die Bewegungen im Vergleich sehr gut kontrollierbar. Kraft war hier ohnehin nie ein Thema, lediglich die Lautstärke ist etwas höher. Die Hebeservos waren hier problemlos, daher bleiben die erst mal drin.

Plötzlicher Kontrollverlust
Ein richtig nerviges Ding war, das immer wieder und plötzlich alle Servos kraftlos wurden. Im Code war das nicht zu begründen, schien sich aber bei komplexeren Bewegungen aller Servos zu häufen. Danach war das System nur durch Neustart mit Powercycle wieder zur Kooperation bewegen. Der ESP hat dabei aber immer fröhlich weiter gemacht, nur hat es die Servos nicht mehr interessiert. Nach etwas Fehlersuche schien der I2C-Bus, über den der PCA9685 angeschlossen ist, die Grätsche zu machen. Nach etwas Netzrecherche scheint es wohl Probleme mit dem ESP32 zu geben, wenn zeitgleich die serielle Schnittstelle und der I2C-Bus am Werkeln sind. Keine Ahnung ob das nun wirklich so stimmt, bleiben konnte es so nicht. Da das Gamepad zwingend eine serielle Verbindung braucht, muss dann halt der Servocontroller weichen. Der zickte ja auch beim Einschalten rum (harte Ausschläge der Beine beim Initialisieren der Lib) und sollte in einer späteren Version auch ersetzt werden, daher gleich weg damit.
Der ESP triggert nun direkt per I/O die PWM-Eingänge der Servos. Damit das einigermaßen ordentlich funktioniert, musste auch schon mal eine erste Version einer Stromverteilerplatine dazu, die sowohl Servokabel, Strom als auch Signale zusammenbringt. War auch erst später geplant, aber was solls. Die erste Version ist leider wieder löttechnischer Pfusch, tut aber erst mal. Für das nächste Modell muss das aber nochmal und richtig gemacht werden.

Grenzen des PWM
Da nun der Servocontroller in den ESP gewandert ist, muss nun auch eine passende Lib dafür her. Die gibt es zuhauf und verwenden (fast alle) das eingebaute PWM-Modul. Leider hat der ESP32 damit „nur“ 16 unabhängige Kanäle, damit für das spätere 18DOF-Modell Zuwenig. Wenn ich aber schon umbauen muss, dann auch so dass die Lösung nachher auch weiterverwendet werden kann. Bei der Suche nach einer Lösung ist mir eine Library untergekommen, die mit einem Timer und Interrupt arbeitet und (mit kleinen Anpassungen und auch gemäß der Meinung des Entwicklers) auch deutlich mehr Servos verkraftet (Link). Mit etwas Try&Error und der Verteilerplatine hat sich tatsächlich eine stabile Lösung zur Servoansteuerung gefunden, die auch mit den geplanten 18 Servos klarkommen sollte. Die Ansteuerung haut auch nicht unkontrollierte Bewegungen raus wie beim Servocontroller. Im Code ist der Umstieg relativ schnell getan, und bis auf kleine Anpassung der Parameter in der Berechnung und Initialisierung funktionierte es auch fast Out-of-the-box. Leider hatte der Ansatz mit dem Timer Anfangs auch Probleme gemacht, da auch der Scheduler so arbeitet und der Überwachungsthread hier mit der Servolib den gleichen Timer verwenden wollte. Nachdem das klar war auch kein Problem, zumal ich die Überwachung in dieser Lösung eh nicht brauche.

Ruckelnde Bewegungen
Eigentlich war ja die Bewegungssteuerung für mich das interessante an diesem Projekt. Umso ärgerlicher war es, dass ich es bisher nicht geschafft hatte eine flüssige Bewegung ohne ruckeln zu bekommen. Entweder die Servos auf Vollgas laufen lassen (und damit zu schnell) oder ruckeln. Zwar wurde das Ruckeln immer formvollendeter, aber es blieb dabei. Nachdem mit den ganzen Änderungen zumindest ein stabiles System erreicht worden ist, ging es also wieder an die Steuerung. Eigentlich war es klar, dass die Steuerung nicht schnell genug durch die Regelschleifen kommt und dadurch ruckelt. Normalerweise sollte durch Anpassen der Scheduler-Konfiguration das leicht anzupassen sein, aber irgendwie brauchte der Code einfach zu lange. Der ARM-Kern sollte aber locker genug Leistung haben, zumal vergleichbares auch schon mit 8-Bit ATMEL-CPUs gemacht worden ist. Irgendwann (eher durch Zufall) hatte ich plötzlich eine saubere, ruckelfreie Bewegung, und zwar einfach durch Abschalten der Debug-Meldungen. Tatsächlich bremsen die Debug-Meldungen am seriellen Bus das System derart aus, das alle anderen Parameter schlicht nicht mehr zum Tragen gekommen sind. Nachdem das klar war, ging es in Riesenschritten zu im Vergleich schon sehr guten Bewegungen.

Der macht was er will
Ein letztes Thema ist aber immer noch, dass immer wieder das System eigenwillig in die Ruhelage steuert (egal was ich am Gamepad mache). Hier hatte ich vorher noch die Hardware oder die Servos im Verdacht, tatsächlich ist es aber ein Standardverhalten des Dongles für den PS2-Controller, wenn die Verbindung abbricht. Das System bekommt das nicht mit (der Dongle verhält sich wie ein Gamepad ohne Input), lediglich der Controller selbst blinkt dann als Hinweis auf den Verbindungsverlust. Es scheint, als on der Dongle nicht zu nah am ESP sein darf, weil sonst die Verbindung abbricht. Naja, auch nicht unmöglich zu lösen, wenn man es weiß.

Fazit:
Natürlich ist das Teil immer noch eine Bastelei. Allerdings sind viele der Anpassungen, die erst fürs nächste Modell geplant waren bereits umgesetzt und wieder neues dazu gelernt worden.
Die Steuerung macht schon richtig Laune, und im Übermut konnte ich sogar kleine Hopser mit dem Teil fabrizieren. Jetzt geht es aber zurück an die eigentliche Aufgabe, nämlich dem Teil endlich das Gehen beizubringen (soweit halt möglich mit den eingeschränkten Freiheitsgraden).

Hexapod – Wir werden besser

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

Hexapod – wir lernen laufen

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

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 ...
Weiterlesen …

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 ...
Weiterlesen …

Hexapod – wir lernen laufen

2020-11 | Projekte

Die Hausspinne hat inzwischen Fortschritte gemacht, genug um den neuen Stand in einem Text zu beschreiben. Verbesserungen im Steuerprogramm, neue Schnittstellen und ein Gamepad als Eingabegerät machen die weitere Entwicklung einfacher und auch mehr Spaß.

Projekt: Hexapod 12 DOF

Kontakt: Boris Dirnfeldner

Link: – eigenes Projekt –

Die Hausspinne basiert ja auf einem fertigen Design (beim Druckmodell) und eigener Software. Nach den ersten Versuchen haben sich schnell auch erste Defizite gezeigt und die Detailprobleme, die das vorhandene Konzept hat.

Änderungen und Verbesserungen Mechanik/Elektronik:
Das Thema Schüttellähmung hat sich mit besser angezogenen Schrauben vermindert, wenn auch nicht gelöst. Hier sind wohl bessere Dämpfungslösungen im Design erforderlich oder eine andere Form der Kraftübertragung von den Servos, das ist aber für die „Lernversion“ nicht mehr relevant. Leider hilft das Festschrauben auch nicht beliebig, weil irgendwann die Servos nicht mehr gegen die Reibung ankommen.
Bei der Stromversorgung hat sich der Ansatz mit dem 18650-Shield nicht bewährt. Der hat einfach nicht genügend Saft um schnelle und komplexe Bewegungen mit ausreichend Strom zu unterstützen und schaltet immer wieder wegen der Überlastung ab. Hier wurde nun auf Modellbau-Komponenten umgestellt, mit einem 3S Lipo, einem Festspannungs-SBEC und entsprechenden Kabeln/Steckern. Damit sollte für das Modell die Stromversorgung geklärt sein.
Den Arduino UNO hatte ich ja bald schon ersetzt durch einen ESP32, der neben deutlich großzügigeren Speicherbedingungen auch mehr Prozessorleistung bietet. Mit jeder Software-Erweiterung sieht man aber den erhöhten Bedarf, so dass der Umstieg ohnehin zeitnah notwendig gewesen wäre.
Neu ist die Anbindung eines PS2-Controllers per Funkdongle. Das Teil hatte ich schon mal in Verwendung, zumindest die Hardware war also wenig problematisch.
Da für die Version damit die Hardware definiert und ausgereizt ist, wird es wohl noch angepasste Druckteile geben um den Ausbau auch sicher zu befestigen.

Software:
Hier wird am meisten gearbeitet und hier gibt es auch am meisten zu tun.
Zum einen werden die Gelenkservos nun mit 50Hz angesteuert und laufen damit weniger hakelig als vorher. Die Steuerung des Gesamtsystems hat nun einen eigenen „Steuerungs-Thread“ und ist damit auch für komplexere Ansteuerung gerüstet. Die Bewegungssequenzen sind nun auch präziser, da nicht mehr jedes Gelenk einzeln angesteuert wird, sondern alle Servos zusammen (und fast zeitgleich) aktualisiert werden. Dadurch wird auch der erforderliche Code für die Bewegungen kürzer und übersichtlicher. Die einzelnen Gelenke laufen auch jeweils in kleinen „Threads“ und interpolieren die geforderte Bewegung in der gewünschten Geschwindigkeit (allerdings bisher noch linear).
Über die Kommandozeile ist es nun auch möglich Kommandos auf Gelenkebene und für das Gesamtsystem direkt per USB-Verbindung einzuspeisen und sich so komfortabler an mögliche Bewegungen ranzutasten. Ohne Try&Error geht da fast nichts, zumal nicht jede Bewegung theoretisch sicher abgeschätzt werden kann.
Auch muss ich so nicht mehr jeden Versuch erst mal als Programm neu übertragen, was auf Dauer auch das Flash ausnudelt.
Da die Kommandozeile auf Dauer auch keine Laune macht, vor allen nicht wenn es um Timing-Fragen geht, ist nun ein PS2-Spielecontroller mit Funkverbindung im System. Eigentlich ein bekannter Kandidat, allerdings nur auf den Arduinos. Mit dem ESP32 gab es einige hakelige Punkte die erst mal (in der Library) angepasst werden musste. Nach ein paar Stunden Fluchen, Suchen, Umstecken und weiteren Fluchen macht das Teil endlich wieder was es soll. Aber so richtig Lustig war das nicht, zumal ich da keine derartigen Probleme erwartet hatte.
Aktuell ist der Fokus der Entwicklung also in den Bewegungen des Systems und den Übergängen zwischen Kommandos. Auch wird alles für ein 18DOF Modell vorbereitet um hier die Anpassungen übersichtlich zu halten. Je mehr ausprobiert wird, desto öfter finden sich auch kleine Bugs die natürlich auch rausgearbeitet werden.

Mit dem Gamepad hat nun auch der Sohnemann den ersten Kontakt mit dem neuen Stubenmitglied und schon (für den geringen Funktionsumfang) viel Spaß. Hier noch ein kurzes Video mit den ersten Versuchen mit Gamepad und Lipo nach Umbau:

Planspiele NextGen:
Mit den Erfahrungen gibt es natürlich auch den Wunsch nach Verbesserung. Am aktuellen Modell wird nicht mehr viel geschraubt, und die fehlenden Freiheitsgrade sind nicht auszugleichen.
Nebenher wird also die neue Generation schon mitentworfen. Folgende Rahmenbedingungen zeichnen sich bereits ab:

  • Das Basisdesign orientiert sich an einem Nachbau des bekannten PhantomX AX von Trossen Robotics. Um die Kosten im Rahmen zu halten, wird dort mit MG996R Digitalservos gearbeitet. Scheinbar kraftvoll genug, 18DOF, kugelgelagerten Gelenken, einem geeigneteren rechteckigen Layout und genügend Platz alles drauf zu montieren. Der Grundaufbau mit kleinem Akku sollte mit ca. 200€ Materialkosten möglich sein.
  • Die Ansteuerung der Servos wird direkt vom Controller erfolgen anstatt über den bisher verwendeten PCA9685. Zum einen ist der I2C-Bus ein potentieller Flaschenhals bei schneller Ansteuerung aller Servos, zum anderen möchte ich bessere Kontrolle über die Ansteuerung bekommen. Der ESP32 hat hierfür genügend I/Os, sollte also passen.
  • Die Stromversorgung wird ähnlich ausgeführt, benötigt aber einen leistungsfähigeren SBEC. Eine Version mit 20A sollte normalerweise genügen und ist bestellt. Der könnte dann auch mit leistungsfähigeren Lipos umgehen, falls notwendig.
  • Die Fernsteuerung per PS2-Controller bleibt. Je mehr die Software bietet, desto höher ist der Nutzen einer solchen Steuerung.
  • Die Software sollte sich nahtlos umstellen lassen, natürlich mit einigem an Feintuning. Durch die zusätzlichen Freiheitsgrade sollte es aber speziell bei Bewegungen in eine Richtung wesentlich flüssiger und ohne das ausgeprägte Gerutsche laufen.
  • Ein Feedback über die Gelenkpositionen wäre wichtig, aber noch ungelöst. Eine Option wäre ein Rückkanal über Potis, dafür fehlen dem ESP aber die benötigten Eingänge. Eine Idee sind hier Analogmultiplexer, aber das muss sich erst noch zeigen.
  • Auch wäre es sinnvoll, an den Beinspitzen ein Feedback für Kontakt zu bekommen. Das geht z.B. mit Mikroschaltern oder über Drucksensoren. Auch hier ist es noch nicht klar wohin die Reise geht.

Natürlich gibt es Tonnen an weiteren Ideen und erforderlichen zusätzlichen Arbeiten, aber auch hier ist die Basisplattform erst mal das wichtigste.

Fazit:
Es bleibt also spannend und weiterhin viel zu tun. Es zeigt sich aber, dass es in die richtige Richtung geht und die Ergebnisse werden mit jedem Versuch besser. Das NextGen-Projekt wird aber auch erst 2021 starten und dann vermutlich auch einige Zeit brauchen, zumal ich dann hoffentlich auch wieder in regulären (Brot&Butter-) Projekten zu tun habe.

Hexapod – Wir werden besser

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

Hexapod – wir lernen laufen

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

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 ...
Weiterlesen …

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 ...
Weiterlesen …

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".
Weitere Informationen