Hexapod – wir lernen laufen

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

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

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

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. Die Dinger sind einfach cool und die Steuerung dazu hat auch einen gewissen Reiz. Da ich derzeit pandemiebedingt deutlich mehr Zeit habe sollte ich endlich mal anfangen und das Teil auf den Weg bringen.

Projekt: Hexapod 12 DOF

Kontakt: Boris Dirnfeldner

Link– eigenes Projekt –

Ziel:
Um sich an das Thema ranzutasten, soll es erst mal ein fertiges Modell aus dem reichen Fundus von Thingiverse.com sein. Da es primär dazu dient etwas Spaß zu haben und was dabei zu lernen, bleibt es kleines Modell mit Mikroservos und einfacher Elektronik. Wenn möglich, sollten Bestandsteile Verwendung finden.

Konzept:
Ein tolles Modell findet sich schnell hier. Das Modell Hexro von Nuttapon Poncharernpong bietet 12 Freiheitsgrade (2 Gelenke pro Bein, 6 Beine) und eine symmetrische Anordnung. Vorgesehen sind SG90-Servos die sehr günstig zu bekommen sind. Die Ansteuerung dazu kann ich mit einem PCA9685 Modul einfach bekommen. Als Controller ist erst mal ein Arduino Uno drin, später dann wahrscheinlich ein ESP32 (wegen dem WLAN-Interface). Stromversorgung soll über ein 18650 Li-Ion Akku mit einem fertigen Halter nebst Ladeelektronik funktionieren. Am Ende wäre das Ding also kabelunabhängig.

3D-Druck:
Das Modell kann gut über meinen Ender-3 gedruckt werden. Die ersten Drucke mache ich mit schwarzen PLA, dass im Ergebnis recht steife Modelle schafft. Leider bekomme ich damit (zumindest bei einem Teil) die Stützstrukturen nicht rausgebrochen (entweder das Teil oder das Werkzeug bricht).
Daher Wechsel auf eine weiße Variante mit der dann am Ende alles recht ordentlich läuft. Ich brauche aber sehr viele Teile (in Summe 50), daher dauert das Drucken doch ein paar Tage. Vom Ergebnis bin ich selber positiv überrascht, bisher ist das sowohl mein größtes Printprojekt als auch mein erstes an dem wirklich eine gewisse Genauigkeit erforderlich ist. Nach dem üblichen Anfangsproblemen (Leveling, Parametrisierung) kommt aber ein Teil nach dem anderen raus, und bis auf einem Filamentbruch im Extruderschlauch auch ohne Probleme.

Aufbau:
Hier kommt die nächste Überraschung, es funktioniert einfach. Die Servos lassen sich gut montieren und die Teile passen ziemlich gut zueinander. Bis auf die eigentlichen Gelenke muss ich praktisch nix nacharbeiten. Die benötigten M3-Schrauben habe ich auf Lager und in den richtigen Längen. Tatsächlich sitzen die auch ohne Muttern gut genug, daher wird erst mal so aufgebaut. Am Ende gibt es nur an einer Stelle (die Servohalterung an der Basis) das Problem, das die dem Servo beigelegten Schrauben zu kurz sind um sicher zu greifen. Da muss ich noch Ersatz beschaffen und nacharbeiten. Auch die Verbindungen zwischen den zentralen Platten sind leider nicht festsitzend genug, auch da wird es nochmal nacharbeiten geben. Die Servoarme brauchen auch noch Schrauben zur Befestigung an die Modellteile, muss ich leider auch bestellen. Bei Kleinstschrauben fehlt mir einfach der Bestand.
Bis auf die meisten Servos und ein Paar Schrauben musste aber sonst nichts nachgekauft werden.

Elektronik:
Der Aufbau ist recht einfach. Der Arduino und die Stromversorgung sind fertige Teile und die Anbindung an den Servocontroller über I2C-Bus auch inzwischen kein Thema mehr. Lediglich die Servoleitungen (12) erfordern Konzentration und Frickelarbeit. Erst mal ist auch nur ein provisorischer Aufbau notwendig, da es ja immer noch offene Punkte beim Modell gibt und ich nicht wieder alles zerlegen will. Und der Umbau auf den ESP ist ja auch noch einzuplanen.

Software:
Auch hier profitiere ich vom Bestand. Meine Softwareumgebung mit meinen Libs hat aber schon lange keinen Arduino Uno mehr gesehen (ich nehme zumeist den ESP32) und zickt blöderweise rum. Also erst mal hier die Bugs raus und weiter im Text. An sich hatte ich früher schon mal die wichtigsten Klassen für ein Hexapod vorbereitet, damit stehen Architektur und einige theoretische Überlegungen und Designentscheidungen. Die Ansteuerung des PCA9685 ist mit den Arduino-Libs trivial und funktioniert auch sofort. In Summe bekomme ich das System schon nach wenigen Stunden dazu das es funktionieren sollte. Testlauf mit nur einem Bein sieht auch gut aus, der Rest wartet erst mal auf das fertige Modell.

Fazit:
Bisher läuft es gut mit der Hausspinne. Bis auf die Zwangspause wegen der Schrauben hat es keinen Showstopper gegeben und die wenigen Probleme konnten mit Geduld, Bier und Zeit gut gelöst werden. Auch die Steuerung scheint gut auszusehen und so freue ich mich darauf das Ganze richtig zusammen zu sehen. Sobald die Schrauben da sind….

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

Mobiles (Alt-)Holzlager

Wenn man eine Menge am Haus und im Garten arbeitet, sammelt sich immer wieder etwas Holz an. Erfahrungsgemäß findet sich immer wieder Bedarf dafür, aber kein echter Platz. Also liegt das Zeug immer im Weg. Darüber hinaus ist es auch nicht richtig gelagert und verwirft sich nach schon kurzer Zeit. Wenn man es dann wirklich braucht, hat man nur daraus schon wieder Probleme die es nicht braucht.

Projekt: Mobiles Holzlager

Kontakt: Boris Dirnfeldner

Link– eigenes Projekt –

Ziel:
Ich brauche eine Ablage, auf der ich Holz platzsparend aber stabil zwischenlagern kann. Idealerweise sollte es trocken gehalten werden und nicht feucht. Mangels Platzes muss das Teil an der Stirnseite des Carports an die Wand passen und als Krönung beweglich sein. Der Aufbau soll aus Bestands- und Restmaterial realisiert werden ohne Neuanschaffung von Material.

Konzept:
Die Idee ist mir beim Hinterherfahren eines Glasereilasters gekommen. Aus den Arbeiten an einem neuen Gartenhäuschen sind eine Rigipspalette und einzelne Lagerhölzer übriggeblieben. Aus früheren Lieferungen liegt noch eine Europalette rum, die ich schon mal mit Rädern versehen hatte und einem Haken zum Bewegen. Die große Palette ist trotzdem relativ leicht und kann wie für Glas schräg auf der Europalette montiert werden. Durch die Räder ist das ganze ausreichend mobil. Zur besseren Stabilisierung kann der Aufbau nach hinten gegen den Carport abgestützt werden.

Aufbau:
Das Ganze ist sogar für mich leistbar. Im Carport lässt sich der Aufbau provisorisch platzieren und sieht schon so gut aus. Die Rigipspalette wird etwa mittig auf die Europalette platziert und etwa bis zum Ende der Palette geneigt. Dadurch bleibt der Schwerpunkt innerhalb der Palettenfläche und die Kippgefahr gering(er). Unter der Europalette sind 5 Räder wie bei einem Würfel mit Augenzahl 5 montiert. Damit ist auch die Last insgesamt gut abgestützt. 3 Räder sind als Lenkrollen ausgeführt, 2 als Bockrollen. Die Rigipspalette wird hinten durch 2 Resthölzer aus der Terassensanierung mit jeweils einem Scharnier aus der Solarmodulaufständerung verbunden und unten an die Palette mit Metallwinkel verschraubt. So kann ich relativ schnell eine andere Neigung realisieren. Der Boden ist an den Seiten mit Lagerhölzern versehen zum Absichern gegen Verrutschen, ebenso an einer Seite der Rigipspalette. Ein Teil des Bodens ist außerdem mit einem Reststück einer OSB-Platte ausgelegt, da sonst Holzplatten nicht gut auf der Europalette aufliegen können. Ein Paar Spanngurte sollen das Material gegen Umstürzen sichern.

Einlagern und Test:
Der Aufbau erlaubt es sowohl Holzplatten als auch Latten sauber und etwas geneigt abzulegen. Durch die Stützhölzer findet sich immer eine Position zur sauberen Ablage. Die geneigte Palette erlaubt dabei gleichzeitig das Holz über die gesamte Länge zu stabilisieren. Natürlich passen keine Unmengen drauf, aber für meinen Bestand ist das Teil genau richtig. Für mich etwas unklar war die Mobilität der Lösung. Also das Teil nun beladen und mit einigen Respekt an seinen finalen Platz verschoben (das Auto ist außer Reichweite und ich sprungbereit). Die Lenkräder sind etwas schwergängig, aber es lässt sich gut alleine und ohne Schreckmomente verschieben und platzieren. Auch scheint der Schwerpunkt passend zu liegen und die Abstützung ausreichend stabil, zumindest fängt da nix zum Schwanken, Neigen oder Kippen an. Ich würde zwar trotzdem nicht damit zum Spaß spazieren fahren, aber mal aus dem Weg stellen ist sicher drin. Wo es nun steht liegt die Rigipspalette auch gegen einen Tragebalken an und ist damit auch absolut stabil nach hinten abgesichert.

Fazit:
Ich finde das Teil super. Es liegen Bretter und Latten nun sauber auf und dürften sich so weniger verziehen. Trocken gelagert ist das Material auch und wettergeschützt ohnehin durch den Carport. Zum ersten Mal hat das Material einen geeigneten Platz und eine korrekte Lagerung, und ich finde das Zeug auch leichter ohne erst mal danach suchen zu müssen. Lediglich Material mit einer Länge ab ca. 2,3m ist hier wahrscheinlich zu groß dafür, aber davon habe ich derzeit nur ein Brett und alles kann man halt auch nicht immer haben. Und da ich ausschließlich Restmaterial und ausgebaute Winkel verbaut habe (nur die Schrauben waren neu), ist sogar der Upcycling-Gedanke sauber umgesetzt.
Manchmal klappt es auch mit einem Holzkopf was Sinnvolles zusammenzuzimmern!

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.

Smartes Energiemanagement – Trippelschritte voran

Die Solaranlage liefert inzwischen viele nützliche Daten und Strom. Der Stromzähler liefert nun auch entsprechende Details. Eine der Fragen dabei ist, wie ich das Erzeugungsprofil der Anlage und unser Nutzungsprofil zusammen bekomme und welche Profile sind das überhaupt? Und passt die Anlagendimensionierung so oder wäre es doch sinnvoll mehr davon zu haben?

Projekt: Smart Power Manager

Kontakt: Boris Dirnfeldner

Link– eigenes Projekt –

Situation Solaranlage:
Obgleich so langsam der Herbst da ist und die Anlage nun schon erkennbar weniger Leistung liefert als noch im August, vor allem durch die geringeren Sonnenzeiten und das ausgeprägter bedeckte bzw. nebelige Wetter, kommt dann (wenn die Sonne durchkommt) immer noch einiges rüber. Natürlich immer in Relation zur Anlagengröße (ist ja ein Kleinsterzeuger mit 600Wp).
Das Monitoring ist inzwischen stabil und die meisten Bugs gefixt. Eine Weboberfläche liefert mir sehr genaue Informationen und hat inzwischen auch eine hinreichende Reife.
Eine nun konsequente nächste Frage ist, ob sich eine Erweiterung der Solarerzeugung (z.B. Carportdach oder Hausdach) lohnt und wie das Setup dafür aussehen muss. Oder welche Voraussetzungen müssen erfüllt sein, damit sich das lohnt?

Situation Monitoring Smartmeter:
In den letzten beiden Wochen konnte ich auch das Erfassen der Daten aus dem Energiezähler im Sicherungskasten stabil bekommen. Es werden nun die Bezugs- und Einspeisedaten sicher erfasst und stehen im Netz zur weiteren Verwertung zur Verfügung. Eine rudimentäre Weboberfläche zeigt mir die aktuellen Daten auch bei Bedarf an, aber da hänge ich eher in der Datenbank, wenn ich was wissen will. Das Smartmeter ist bei den Zählern ist um den Faktor 10 genauer als die Solaranlage (1Wh statt 10Wh) und gibt auch bei Messungen 4x die Minute noch Änderungen sicher an. Da dies auch für den Einspeisezähler gilt, kann die „Ungenauigkeit“ der Solaranlage hier etwas ausgeglichen werden.

Konzept Powermanager:
Datenerfassung ist ja ganz lustig, sollte aber auch was bringen. Als erstes benötige ich mal eine Aussage wie es aussieht, wenn ich Strombezug, -verbrauch und -einspeisung miteinander in Bezug bringe.
Da ich die beiden Datenerfassungsgeräte vorerst nicht weiter mit anderen Aufgaben belasten möchte, ist dafür ein weiterer Raspberry im Büro angedacht. Das Teil ist derzeit nur als zentraler MQTT-Server tätig, hat also massig freie Zeit und ohnehin die Rolle einer „Zentrale“.
Auf Basis der bereits vorhandenen Skripte soll es wieder eine vergleichbare Lösung sein, die zum einen die Daten der beiden Logger einsammelt, diese verdichtet und dann in eine eigene Datenbank abspeichert. Relevante Daten werden (erst mal) wieder per Weboberfläche dargestellt.
Zum Einsammeln bieten sich die MQTT-Sendungen der Logger an.

Software:
Einiges an Code ist ja schon vorhanden. Da ich mich über einige Codedubletten ärgere und ein Paar andere technische Schulden, geht es an alle 3 Pakete parallel. Code wird in ein Modul ausgelagert, vereinheitlicht und an ein Paar Stellen robuster gestaltet. Die MQTT-Meldungen mit den aktuellen Daten werden aufgenommen und verdichtet. Es stellt sich allerdings heraus, dass dieses System zwar gut und auch relativ stabil funktioniert, aber auch ziemlich umständlich ist, weil die Verarbeitung ausschließlich extern getriggert wird (durch die MQTT-Pakete) und damit auf viele Dinge geachtet werden muss. Die Lösung erscheint mir in der Folge dann doch zu anfällig und komplex, daher wurde das Konzept umgestellt auf eine Erfassung durch REST-Anfragen an die Logger direkt auf die Datenbanken. Dazu wurden in den beiden Skripten, die für die Weboberflächen zuständig sind, zusätzlich eine RESTful-Api reingepackt (die Oberfläche hat bereits eine Flask-basierende Basis) über die ich SQL-Anfragen ausführen kann. Damit bin ich wieder bei aktiven Anfragen basiert auf Scheduler-Zeitsteuerung und weg von den vielen Sonderfällen der event-basierten Bearbeitung. Derzeit laufen beide Schienen parallel, was mir die Prüfung der Daten erleichtert. Im Ergebnis bekomme ich nun die Daten für die Stromerzeugung, Strombezug und Stromeinspeisung in Tabellen gepackt in den Auflösungen Minute, Stunde und Tag. Dazu wird der Eigenverbrauch (also Erzeugung – Einspeisung) und der komplette Stromverbrauch berechnet (also Solarstromverbrauch + Bezug). Da die Solaranlage nur in 10Wh-Schritten die Zähler aktualisiert, sind Auflösungen <1 Minute hier nicht mehr sinnvoll.

Erste Erkenntnisse:
Die Daten sind ein wichtiger Schritt vorwärts. Leider funktioniert die exakte Korrelation auf Minutenbasis wegen der geringeren Messauflösung der Solaranlage nicht so gut, wenn nicht viel Sonne da ist (mehrere Minuten nix, dann wieder ein Block von 10Wh). Spätestens auf der Ebene Stunde ist das aber egal. Zur Erkennung einer Überversorgung durch die Solaranlage kann ich aber mit den Daten des Smartmeters arbeiten. Ich sehe weiterhin eine fast vollständige Verwertung der erzeugten Leistung, allerdings auch Überschuss, wenn die Sonne mal Gas gibt. Die Solaranlage ist damit recht gut für die Grundlastversorgung ausgelegt. Durch die Messauflösung von einer Minute kann ich auch gut Verbrauchsprofile sehen, z.B. wenn der Backofen aktiv ist. Damit kann ich nun ziemlich genau sagen, wann ich welche Energiemengen benötige (und wann nicht). Dampfbügeleisen und Backofen sind hier wohl die Könige des Strombezugs, dann Herd, Geschirrspüler und Waschmaschine.

Verbrauchs- und Erzeugungsdaten:
Über Nacht zieht das Haus aktuell etwa 250W. Tagsüber liege ich etwa 100W drüber. Damit brauche ich ca. 6KWh täglich zur Grundversorgung. Im realen Verbrauch sehe ich 10-12 KWh an normalen Tagen. Die Solaranlage lieferte an guten Sonnentagen bis zu 617W (Begrenzung durch den Wechselrichter), über den Tag aktuell bis zu 3 KWh, an optimalen Tagen knapp 4 KWh maximal.
Die Einspeisung ist vernachlässigbar (seit April 14 KWh), aber an guten Sonnentagen in der Spitzenzeit gut erkennbar.

Solaranlage erweitern oder nicht?
Es zeichnet es sich jetzt schon ab, dass ich mit zusätzlicher Anlagenleistung ohne Speichermöglichkeit meistens nichts anfangen kann bzw. nur relativ kurze Spitzenphasen besser abdecken kann. Damit ist auch erst mal die Frage einer Anlagenerweiterung vom Tisch, bis ich entweder einen bezahlbaren Stromspeicher finde oder geeignete Verbraucher mit Steuerungsmöglichkeit. Das Einspeisen ins Stromnetz ist derzeit eher unattraktiv, weil die Refinanzierungszeiten mir persönlich da noch deutlich zu lange sind und die Erträge zu gering. Erste Angebote mit Speichermöglichkeiten über die Netzversorger („Strom-Cloud“) finde ich zwar konzeptionell interessant, sind allerdings auch bisher nicht attraktiver als Einspeisung und günstiger Ökostrombezug. Umgekehrt sind die Stromspeicher auch noch zu teuer, was wiederum zu lange zur Refinanzierung braucht. Und nur zum Spaß ist mir das Ganze dann derzeit zu aufwändig und auch zu teuer.

Weiterer Ausblick:
Mit dem direkten Vergleich Einspeiseleistung gegen Bezugsleistung kann ich nun Schaltschwellen für Verbraucher definieren, die nur bei Sonnenstromüberschuss laufen sollen.
Die Logik dafür kann im Logger des Smartmeters dazu gebaut werden und dann z.B. über MQTT wieder entsprechende Benachrichtigungen verteilen.
Ein erster Kandidat wird wohl eine Umwälzpumpe zur Algenbekämpfung im IBC-Wassertank sein, auch als Proof-of-Concept. Die Poolpumpe bleibt ein ständiger Kandidat, und mit etwas guten Willen und Zeit finden sich sicher weitere Kandidaten.
Ein kleiner Stromspeicher mit steuerbarer Leistungsregelung wäre eine Idee um mehr (zusätzliche) Solarleistung nutzbar zu machen, verbietet sich aber derzeit noch aus Kostengründen.
Vorerst werden aber fleißig weiter Daten gesammelt, auch um eine bessere Idee zu bekommen wie die Jahreszeiten hier Einfluss nehmen.

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