Houston – wir haben ein Bild

Das ewige An-die-Anlage-Latschen-um-Leistungsdaten-zu-bekommen ist mir nun endgültig zu blöd, zumal es bei mehr als 35° noch weniger Laune macht als sonst. Es ist also mehr als dringend geboten endlich die Daten vernünftig zu erfassen. Auch um zu verhindern, das ich mir doch noch das überteuerte Gateway vom Wechselrichterhersteller kaufe und alles in die Cloud schicke.

Projekt: Solaranlage

Kontakt: Boris Dirnfeldner

Link– eigenes Projekt –

Situation:
Das hinterste Modul auf der Südseite ist auf die Ostseite umgezogen und unterstützt das schon vorhandene Testmodul in seiner Tätigkeit bis ca. Mittag. Zwar ist die Kabelage immer noch vorläufig, aber grundsätzlich vollständig.
Die beiden Südseite-Module sind noch nicht aufgeständert, auch weil es für derartige Arbeiten derzeit einfach zu heiß ist. Jeweils ein Modul auf der Ost- und Südseite sind parallel an einem String angeschlossen.

Elektronikumbau:
Am Wechselrichter bleibt bis auf die Beschaltung alles gleich. Der Sicherungskasten erfährt aber ein klares Upgrade. Neben dem Raspberry mit Hutschienengehäuse und einem entsprechenden 5V-Netzteil gibt es den RS-458- USB Adapter vom Versuchsaufbau. Leider hat sich ein anderer Kandidat als Reinfall erwiesen, daher bleibt es beim funktionierenden Testadapter. Überspannungsschutz und Sicherung kommen aus der „alten“ Box. Der Schalter an der Frontseite wird durch eine Variante ersetzt, der Phase und Nullleiter unterbricht (bei guter Anlagenleistung haute der alte, der nur die Phase trennte, sonst den FI-Schutzschalter raus).

Software:
Hier gibt es einige Neuerungen. Aus dem vorhandenen Testskript in Python wurde ein Skript zur regelmäßigen Speicherung von Daten in eine SQLite-Datenbank. Erfasst werden Spannung, Strom und Leistung alle 15 Sekunden, die Zählerstände jede Stunde. Ein zweites Skript holt sich die Daten aus der Datenbank und visualisiert diese über Plotly Dash in verschiedenen Ansichten per internen Mini-Webserver. Beide Skripte sind in Python3 realisiert und als Services in Betriebssystem konfiguriert und starten damit automatisch.

Datenbank:
Durch die Verwendung der Datenbank bin ich nun flexibel in der Auswertung. Die Lösung erzeugt etwa 1/2 MB pro Tag an Daten und ist dabei mehr als ausreichend schnell. Mit dem vorhandenen Speicher kann ich sehr lange Daten anhäufen bis es eng wird. Auch sind kleinere Änderungen sehr schnell implementiert und auch die Verwendung in Excel ist mit Tools gar kein Problem. Lediglich die vergleichsweise häufige Nutzung der Speicherkarte könnte nochmal Ärger machen. Aber das lasse ich erst mal auf mich zukommen.

Entwicklungsumgebung:
Obgleich das natürlich auch einfach mit einem Editor wie z.B. Notepad++ klappt, arbeite ich lieber mit PyCharm. Die IDE erlaubt mir sehr viele Tätigkeiten viel komfortabler zu machen als mit (vielen) anderen Tools. Up-/ und Download von Dateien ist vollintegriert, das lokale Git-Repository ebenfalls.
Integriert ist der Interpreter mit Paketmanagement (auch Remote), ein Debugger, ein Tool für den Zugriff auf die Daten der Datenbank und manches mehr. Native Sprachunterstützung für Python zur Syntaxprüfung, Formatierung, Überarbeitung und Dokumentation sind natürlich auch dabei.

Anlagendaten:
Zuerst mal war es doch überraschend, wie gut sich der neue Aufbau (im August) macht. Die Anlage fängt früh (ca. 6:30) mit den beiden Ostmodulen an und verbessert sich über den Vormittag mit dem Sonnenstand. So etwa ab 9 Uhr bekommen die Module auf der Südseite auch das erste (indirekte) Licht und geben anteilig Leistung dazu. Das Ganze steigert sich bis etwa 11 Uhr, wenn die Ostmodule wohl am besten ausgerichtet sind und sie Südseite trotzdem schon Sonne schnuppert. Dann geht die Leistung wieder zurück bis etwa 12 Uhr, wenn die Ostmodule verschattet werden. Der Einbruch ist in den Diagrammen schön sichtbar, danach liefern die Südmodule mit Direkteinstrahlung und die Ostmodule nur noch indirekt dazu. Um etwa 13 Uhr zeigt sich ein weiterer Peak, wenn die Südmodule am besten stehen und danach geht es kontinuierlich bergab mit dem weiter wandernden Sonnenstand.
Könnte ich im Osten auch noch Module platzieren, könnte ich hier eine vergleichbare Lösung für die Nachmittags- und Abendsonne bekommen. Aber dann kann ich nicht mehr in den Carport fahren, und das wäre dann auch wieder doof.

 

Durch die Visualisierung kann ich nun sehr komfortabel in die Anlage „reinschauen“ und sehe in einer bisher nie dagewesenen Granularität, was passiert. Es war z.B. sehr schön erkennbar als ein vergessener Gartenstuhl auf der Wiese am Morgen die Ostmodule teilweise beschattete. Auch sind Wolkenverschattungen sehr schön zu erkennen und natürlich auch andere Wettereinflüsse. Auch neue Rätsel finden sich nun, z.B. hat die Anlage beim Aufreißen der Wolken plötzlich die Maximalleistung des Wechselrichters erreicht und ein Paar Minuten gehalten. Da war wohl wirklich kurzzeitig überproportional viel Sonneneinstrahlung auf die Module geraten.

Ertrag und Nutzung:
Die Anlage liefert in Summe über den Tag weniger als eine auf Ertrag optimierte Dachanlage. Da ich aber keine Einspeisevergütung bekomme (und die Anlage auch zu klein dafür ist), liegt mein Szenario bei der Abdeckung der Grundlast. Aktuell benötige ich hier ca. 300- 400W kontinuierliche Leistung, und die kann die Anlage bis zum frühen Nachmittag bei entsprechendem Wetter liefern. Mit der noch offenen Aufständerung nach Süden sicher noch länger. Aktuell hat die Anlage 164 KWh erzeugt (alleine 18 davon in den letzten 6 Tagen), 3 KWh davon gingen in Summe ins Netz. Damit sollte die Dimensionierung eigentlich passen mit etwas Luft nach oben.

Fazit:
Nun macht das Ganze wieder mehr Spaß. Neben der Tatsache, das die Anlage immer besser arbeitet, speichert sie nun auch die wichtigsten Daten zur Analyse. Wenn mir wieder mal eine Frage im Kopf rumspukt, kann ich nun die Daten z.B. in Excel entsprechend aufarbeiten oder direkt in die Software eine entsprechende Visualisierung reinbauen. Jetzt fehlt nur noch das Aufständern im Süden und die saubere Verkabelung, dann sollte das Teil so passen.

Überlegungen:
Nachdem der Testaufbau zum Auslesen der Anlagendaten per RS-485 endlich funktioniert, geht es nun der Anlage an den Kragen.

Solaranlage im Eigenbau – Organisierte Unmöglichkeit

Die Solaranlage ist technisch fertiggestellt, soweit die guten Nachrichten. Über Speicher & Co will ich derzeit besser nicht schreiben, aber ...

Energieautark in 2023 – Zahlenspiele und neue Strategie

Mit den neuen Regelungen zur Umsatzsteuer 0% für PV-Komponenten und aktuellen Marktpreisen für Komponenten als auch Primärenergie muss die eigene ...

EEG Solaranlage – Darf’s ein Wechselrichter mehr (oder weniger) sein?

Die neue PV-Anlage ist inzwischen ein Mehrjahresprojekt.Schuld ist die allgemeine Lage der Nation und ein unglaubliches Chaos in den Lieferantenketten.Projekt: ...

EEG-Solaranlage – der nächste Schritt

Mit den Erfahrungen aus der "kleinen" Solaranlage ist es nun Zeit den großen Bruder aufzubauen. Diesmal nicht mehr als "Kleinstanlage", ...

Solaranlage – das Erwachen der Macht

So langsam wacht die Natur wieder auf und auch die Sonne macht sich langsam wieder bemerkbar. Grund genug nach einigen ...

NoSolarPower – Wir haben Herbst

Nach den ereignisreichen Monaten bisher in 2020 stellt sich doch langsam heraus, dass es Herbst wird. Die Blätter werden bunter, ...

Solarpower – Energie durch Winkel

Die letzten Monate waren geprägt durch das Sammeln von Erfahrungen. Nun sollte langsam Ruhe in dieses spezielle Projekt kommen, daher ...

Houston – wir haben ein Bild

Das ewige An-die-Anlage-Latschen-um-Leistungsdaten-zu-bekommen ist mir nun endgültig zu blöd, zumal es bei mehr als 35° noch weniger Laune macht als ...

Solaranlage Retrofit – Höhere Sphären

Nachdem die Anlage nun ein Paar Monate in verschiedenen Konstellationen gelaufen ist, zeigen die gewonnenen Erkenntnisse schon deutlich das weiterer ...

Energieneutraler Pool – Etappenziel erreicht

Der energieneutrale Pool als Ziel für dieses Jahr scheint realistisch. Mehrere Maßnahmen greifen gut ineinander und scheinen zumindest dieses Ziel ...

Solare Freiheit – Weiteres Modul und Zahlenspiele

Im Mai war das Wetter solartechnisch bescheiden (nur Wolken und Regen) und die Werte der Anlage so schlecht, das Theorie ...

Solare Freiheit – Erstes Fazit

Nachdem die Solaranlage nun ein Monat gelaufen war, ist es Zeit für ein erstes Fazit. Schatten und Licht liegen nahe ...

Solare Freiheit – Nächste Schritte

Da nun die Solaranlage läuft und Theorie und Praxis sich scheinbar bestätigen, stellt sich nun die Frage nach weiteren Schritten ...

Solare Freiheit – Berechnung und Auslegung

Die neue Solaranlage hat einiges an Vorarbeit gekostet zum richtigen Verständnis und zur richtigen Auslegung. Auch wenn der Artikel nicht ...

Solare Freiheit – Minikraftwerk am Carport

Der im letzten Jahr angeschaffte Rundpool hat sich in Bezug auf seinen Energiehunger als durchaus relevant bewiesen. Dieser Energiebedarf soll ...

RS485 ModBus – Nächstes Level

Das die Messeinheit funktioniert, konnte ich ja schon die letzten Wochen feststellen. Die ModBus RS-485 Schnittstelle konnte ich ja auf Protokollebene auch schon mal erfolgreich antesten. Nun geht es dran, hier eine funktionierende Lösung für die Solaranlage zusammenzubauen.

Projekt: Solaranlage

Kontakt: Boris Dirnfeldner

Link: – eigenes Projekt –

Situation, Probleme und Lösungen:
Nach dem ersten Trockenversuch war ich schon recht zuversichtlich, das die Lösung nun deutlich näher gerückt ist. Die Idee war mit einem ESP32 und einem RS-485 Adapter den PC-Client zu ersetzen und die Messdaten dann im ESP32 mit einem kleinen Webserver zu visualisieren. Letzteres hatte schon recht schnell ganz ordentlich funktioniert (als UI habe ich ESP-DASH verwendet). Dafür hat der RS-485 Anteil so gar nicht wollen. Zum einen ist der ESP32 mit 3,3V unterwegs, ich hatte aber nur Teile für die Arduinos bzw. Raspberries (beide mit 5V Bordnetz). Beim Versuch für 3,3V entsprechende Boards zu bekommen war der erste Einkauf leider nur mit baugleichen Gegenstücken kompatibel. Danach habe ich (vermutlich) eine bessere Alternative gefunden, aber bisher noch nicht verbaut. In der Wartezeit hatte ich im Bereich Software weiter bearbeitet und leider herausgefunden, das die ModBus-Libaries für den ESP32 (eigentlich alle Arduino-Umgebungen) ein Timing-Problem haben und die Kommunikation damit nicht funktioniert. Zwar kann man das auch lösen, aber so richtig wollte mir das nicht schmecken (wenn ich schon die Libs erst mal berichtigen muss kommt sicher noch einiges anderes dazu). In der Kombination gab es mir zu viele (potentielle) Probleme.

Also nochmal einen Schritt zurück und das Konzept überdacht. Ich habe ja schon ein fertiges Python-Skript zum Auslesen im Netz gefunden (war ja als Basis für den ESP32-Code gedacht) und einiges an Hardware rumliegen. Da ich ja einen funktionierenden USB-Adapter für RS-485 habe (getestet) und auch noch diverse Raspberries, ist die neue Lösung nun darauf aufgebaut. Die Library für ModBus scheint hier keine Probleme zu haben und der Raspi ist auch generell flexibler für ungeplante Ergänzungen oder Versuche (der ESP war mit dem Webserver dann schon recht ausgelastet). Für den Raspberry musste noch ein Gehäuse zur Schienenmontage her, ein entsprechendes Netzteil zur Montage auf einer Schiene hatte ich schon. Da nun mehr Platz benötigt wurde, brauchte es auch insgesamt ein Gehäuse-Upgrade. Nebenbei wollte ich ohnehin den „Notaus“-Schalter gegen ein Modell tauschen, das neben der Phase auch den Nullleiter unterbricht (bei einer gewissen Leistung „reisst“ das System sonst den FI im Schaltschrank).

Nachdem alle Teile eingetrudelt sind, wird nun der erste Grundaufbau getestet. Der Raspberry hat das aktuelle Raspian bekommen und wurde in sein Gehäuse eingebaut. Das ganze wird nun mit dem 5V-Netzteil schon mal provisorisch ins Gehäuse reingesetzt. Da ich die Energiezählerklemme derzeit in der Solaranlage benutze, ist der kleine Bruder (mit gleichem Interface) als Testklemme dazugebaut worden. Danach das ganze noch sauber verkabeln und mit einem normalen Haushaltsstecker als Teststromlieferant verbunden.

Der Raspberry musste mit neuen Image noch eingerichtet werden, das Skript draufkopiert und die abhängigen Libs dazu installiert. Dann der erste Start und siehe da, Exception und nix passiert. Wie immer halt, manchmal könnte man schon die Kriese bekommen.

Unmittelbar klar ist schonmal, das das Skript nur auf Python 2.x läuft (Python 3 hat z.B. für print einen anderen Syntax). Aber auch dort kommt es nur zur Exception.
Nach einigen Versuchen stellt sich heraus, das die erforderlichen Libs für die Raspberry-Umgebung leider nicht ganz gestimmt haben. Statt der gelisteten Lib „Serial“ braucht es „pySerial“, dann klappts auch auf dem Bus. Wenn ich „Serial“ dazu installiere, geht es schief. Das Skript holt sich nun die Daten richtig ab. Nach ein Paar weiteren Tests ist nun klar, das der Aufbau sicher funktioniert und die finale Lösung angegangen werden kann.

Die Hardware ist unproblematisch und wird einfach umgebaut werden. Da wird es keinerlei Probleme mehr geben (zumindest bis ich es besser weiss). Nur die WLAN-Reichweite des Raspberries könnte noch ein Thema sein, das wäre es dann aber auch mit dem ESP32 geworden.
Das vorhandene Skript wird ersetzt durch eine Python 3- Variante, die Daten in eine SQLite-Datenbank hinterlegt. Dazu kommt ein zweites Skript, das diese Daten dann als Webservice visualisiert. Wahrscheinlich erfolgt dies mit pydash, muss aber noch ausgetestet werden. Beide Skripte werden dann noch als Service eingerichtet. Die Datenbank schiebe ich dann noch regelmäßig auf das NAS als Backup oder zur manuellen Analyse. Auch wieder ein kleines Skript und etwas Aufwand.

Bewertung:
Mit dem Set habe ich dann eine von den Launen der Hersteller unabhängiges System, alle auch jetzt schon verfügbaren Messdaten und die Option den Raspi sukzessive mit weiteren Funktionen auszustatten. Potential hat das System für viele Erweiterungen, aber erst mal muss die Basis laufen. Als einzigen Nachteil zur Herstellerlösung sehe ich, das die internen Messfühler des Wechselrichters (natürlich) nicht zu sehen sind. Das wäre z.B. die Leistung an den einzelnen Strings. Die sind aber bei meinem Aufbau mit parallel verschalteten Modulen auch nicht mehr so eindeutig, daher egal. Und das der Hersteller für die eingebaute ZigBee-Schnittstelle keine Specs herausgibt ist schon schade. Das er aber dann fast 200€ verlangt für ein (nicht wetterfestes, geschweige den außenbereich-taugliches) Gateway und den Zwang sich an die Herstellercloud zu hängen, ist unverschämt. Wohl dem der sich hier helfen kann und nicht jeden Unsinn mitmachen muss.

Fazit:
Nach etwas Zeit im Abklingbecken kann ich nun endlich den Zielaufbau angehen. Die Basis-Infrastruktur ist getestet, jetzt muss ich das noch umbauen (der nächste Schlechtwettertag kommt bestimmt) und die Software richtig implementieren. Zum Glück kann ich das in mehreren Schritten machen und dann (remote) aktualisieren. Ich freue mich schon auf die ersten richtigen Daten, ohne jedes mal durch den Garten zur Anlage hin zu schlappen.

Der Weg ist das Ziel, aber das Etappenziel kommt näher!

Komponenten:
RS485-USB Converter
DDS238-1 ZN Smartmeter
Raspberry PI3B+
Netzteil-Klemme

Überlegungen:
Das manuelle Ablesen von Leistungsdaten ist doof und die Herstellerlösung zur Darstellung der Wechselrichterleistung ist teuer, cloudabhängig und damit auch doof. Wird Zeit das ich endlich das Monitoring auf die Reihe bekomme.

Houston – wir haben ein Bild

Das ewige An-die-Anlage-Latschen-um-Leistungsdaten-zu-bekommen ist mir nun endgültig zu blöd, zumal es bei mehr als 35° noch weniger Laune macht als ...

RS485 ModBus – Nächstes Level

Das die Messeinheit funktioniert, konnte ich ja schon die letzten Wochen feststellen. Die ModBus RS-485 Schnittstelle konnte ich ja auf ...

RS485 ModBus – Aller Anfang ist schwer

Obgleich ich nur eine Kleinst-Solaranlage installiere, will ich natürlich trotzdem bunte Diagramme zu den wichtigten Parametern sehen. Da das Teil ...

Telegram Bot – Chat mit Raspberry

Mittelfristiges Ziel ist, die ganzen Projekte zusammen zu schließen und auch von außen sicher zu nutzen. Dazu ist ein kleiner Versuch zur Anbindung von Telegram an einen Raspberry gestartet worden. Am Ende ist ein funktionierender Telegram Bot in Python auf einem Raspberry rausgekommen, mit dem vom Handy aus gequatscht wird.

Projekt: Telegram Bot

Kontakt: Boris Dirnfeldner

Link: – eigenes Projekt –

Nach einiger Suche zu Lösungen zur benutzerfreundlichen Anbindung an die eigenen Lösungen bin ich über die API von Telegram gestolpert und die wirklich mächtige Funktionalität der Bots.

Als Einstieg zu dem Thema hat Telegram selbst eine recht ordentliche Seite.

Grob gilt es folgende Schritte zu tun:

  • Erzeuge einen neuen Telegram-Bot über einige Messages mit dem Telegram-Bot „Botfather“. Nach erfolgreicher Erzeugung ist der Bot aktiv und man hat einen exklusiven Schlüssel für den Zugriff
  • Danach geht es daran, den Bot an sich zu entwickeln. Die Telegram-Server funktionieren als Vermittler zwischen den Clients (der App auf den Smartphone) und dem Server (der Python Anwendung auf dem Raspberry). Alle Seiten müssen sich auf den Servern anmelden, damit die Kette funktioniert. Der Bot ist immer aktiv, wenn also nur der Client angemeldet ist antwortet halt keiner. Ohne Client hört halt keiner zu.
    Die Bot-Applikation autorisiert sich gegenüber Telegram über den Schlüssel.

Für Python gibt es einen sehr guten Wrapper um die Telegram-API, zu finden hier.
Da sind auch die erforderlichen Dokumentationen und ein Tutorial zu finden.

Ich habe für meinen Bot ein Paar Kommandos eingerichtet und eine Sicherheitsschicht über User IDs. Die muss ich einmal rausfinden (durch eine Nachricht an meinen Bot). Da ich einen Bot nicht privat schalten kann, muss ich zwischen „autorisierten“ Benutzern und Besuchern unterscheiden. Ebenso kann ich Nachrichten auch nur an bestimmte Benutzer „privat“ schicken und so die Benutzer komplett von der Infrastruktur isolieren.

Wenn keine Kommandos kommen, könnte ich mich z.B. auch mit einer Instanz von ChatterBot unterhalten. Das habe ich mir dann aber gespart, zumal es keinen zusätzlichen Nutzen für mich hat. Aktuell liefet ein Standard-Handler einfach einen Satz zurück. Der Spieltrieb ist manchmal schon übel.
Die Unterhaltungen der einzelnen Clients mit dem Bot sind getrennt voneinander. Wenn also zwei verschiedene Personen verbunden sind, können diese sich nicht untereinander belauschen. Eine Gruppe ist mit Bots nicht möglich.

Die Telegram-Infrastruktur ist in Bezug auf die Nachrichten sehr mächtig und erlaubt eigentlich alle relevanten Medien zu empfangen und zu übertragen.
Ich werde später damit auf Anforderung z.B. Grafiken mit Temperaturverläufen vom Pool anfordern können oder auch nur Alarme von Geräten aufs Handy geschickt bekommen.

Probleme:

Primär mit der API, um nach dem supereinfachen Einstieg das Thema Security voran zu bekommen. Nach etwas rumprobieren und Recherche der Dokumentation ist aber alles lösbar gewesen und eigentlich ohne echte „Klippen“.

Fazit:

Die vorhandene Lösung ist bereits gut einsetzbar und leicht zu erweitern. Sobald das Thema Home Automation weiter getrieben wird und die entsprechenden Projekte eine ausreichende Reife erhalten, wird der Bot auch (zumindest für Teile der Funktion) eingebunden.

„Dif-tor heh smusma“

Komponenten:
Rechner: Raspberry PI 3B+
Language: Python
Runtime: Raspbian
Smartphone mit Telegram App

Überlegungen:
Telegram: Ein recht sicherer Messaging-Dienst, kostenlos und nicht der Google Datenkrake zugehörig. Außerdem eine sehr mächtige API zur Anbindung von Applikationen.

Schäden:
– mal zur Abwechslung keine –

Intelligenter Chatbot mit Lernschwäche – Erste Schritte mit Rasa

Nach einigen anderen Arbeiten war es an der Zeit das Thema Chatbot wieder aufzunehmen. Die letzten Versuche mit Chatterbot und Telegram waren ja ganz nett, aber von "intelligent" waren wir doch weit weg. Nun geht es an das Thema Satzverständnis ...

Telegram Bot – Hirn ist aus

In einem früheren Post hatte ich ja schon über den Telegram Bot als Interface für die Heimautomatisierung geschrieben und die Idee, nicht-Kommandos über einen ChatBot zu bearbeiten. Die Idee ist inzwischen etwas weiter gedacht und erheblich komplexer geworden.Projekt: Telegram Bot ...

Telegram Bot – Chat mit Raspberry

Mittelfristiges Ziel ist, die ganzen Projekte zusammen zu schließen und auch von außen sicher zu nutzen. Dazu ist ein kleiner Versuch zur Anbindung von Telegram an einen Raspberry gestartet worden. Am Ende ist ein funktionierender Telegram Bot in Python auf ...

Rover – Mad Max in Raspberry

Mein erstes Projekt überhaupt war der Aufbau eines Rovers mit zwei Antriebsrädern und einem Stützrad. Ziel dabei war es mit Raspberry und Python eine mobile Plattform für weitere Projekte zu schaffen.
Dabei wurde bewusst erst mal gebaut und dann überlegt ob das alles passt. Fehler waren beabsichtigt, lernen das primäre Ziel.

Projekt: Rover

Kontakt: Boris Dirnfeldner

Link: – eigenes Projekt –

Vorarbeiten:

Als ersten Schritt wird die Ansteuerung des Schrittmotors erst mal fliegend aufgebaut und die ersten Codezeilen erstellt. Nachdem erstmal die einzelnen Kabel an der richtigen Stelle sind, funktioniert der Motor auch relativ gut. Zumindest bei langsamen Drehzahlen. Also erst mal die Grenzen ausloten und mit dem Timing rumprobieren. So ganz ohne Achslast verträgt der Schrittmotor auch abrupte Drehzahländerungen klaglos.

Aufbau Versuch 1:

Nun wird alles auf ein rechteckiges Sperrholzbrett montiert:
o Bleigelakku 12V am hinteren Ende über der Antriebsachse
o Die Motore sind an beiden Seiten am hinteren Ende und unterhalb der Platte befestigt, so das die Reifen seitlich wie bei Traktoren frei standen.
o Als Reifen sind Tretradrollen mit 10cm Durchmesser direkt an der Motorachse befestigt.
o Vorne mittig ein Stützrad aus dem Möbelbau.
o Der Raspberry und Kabelage vorne auf die Platte.

Ergebnis: Sehr lustig, aber sinnlos. Die verwendete Sperrholzplatte mit 4mm bog sich unter dem Gewicht des Akkus schlicht durch, so das die beiden Räder mit ca. 45° Radsturz schräg abstanden. Mit Absicht wäre das Design Cool, so aber ein glatter Fail!

Aufbau Versuch 2:
Alles wieder runter, dann erstmal die Sperrholzplatte mit ein Paar Holzstreben versteift.
Die Teile wieder in gleicher Weise draufgebaut.
Damit wird nun wieder Erfahrung mit der Ansteuerung der Schrittmotore gesammelt und mit dem sehr empfindlichen Timing bei der Ansteuerung von Schrittmotoren in einer ungeeigneten Programmiersprache gelernt. Hohe Geschwindigkeiten sind so schwierig zu erreichen, geschweige den zu halten.
Durch die Umstellung auf „Pigpio“ und entsprechende Nutzung von „Waves“ war das Ansprechverhalten des Schrittmotors in Ordnung.
Dann ergänzend die Steuerung über Controller integriert und man konnte rumfahren.
Leider versagten die Motore schon bei kleinen Stufen wie z.B. bei Teppichen. Durchdrehende Schrittmotore machen einen üblen Lärm. Deswegen sind auch die Beschleunigungs- und Bremsrampen sehr flach, was aber das Gefährt auch sehr träge in der Reaktion macht.

Ergebnis: Immer noch lustig, aber Ok. Wie ein Endzeitgefährt bei Mad Max und mit etwas Deko für ein Steampunk-Modell grundsätzlich geeignet. Lediglich die schwache Antriebsleistung muss gelöst werden.

Aufbau Versuch 3:

Der Antrieb wird umgebaut, die Motore über einen Riemenantrieb (3:1) an die Antriebsachse umgesetzt. Das ganze ist in einem Gehäuse aus dem 3D-Drucker eingebaut, die Achsen mit Kugellagern gesichert. Jede Einheit ist für sich weiter einzeln aufgebaut und spiegelverkehrt aufgebaut. Danach wieder unter der Plattform montiert.

Ergebnis: Jetzt hat das Teil genug Kraft. Mit der vorhandenen Steuerungslogik reagiert das Modell aber weiterhin zu träge auf Steuer- und Bremsbefehle.

Aufbau Versuch 4:

Bisher war der Controller über USB-Kabel am Gefährt angeschlossen, weil die Anbindung per Bluetooth leider zickt. Das ist wohl bei den China-Nachbauten öfters der Fall und leider auch nicht immer lösbar (leider habe ich als Spielkonsolenverweigerer keine originalen Controller zur Hand, und nur zum ausprobieren sind mir die Dinger zu teuer). Pigpio bietet aber an, auch remote-Instanzen zu steuern und daher stelle ich das ganze System auf eine Client/Server-Steuerung um: Ein Raspberry Pi 3B+ mit dem Controller (kabelgebunden) übernimmt das Benutzerinterface, die Pigpio-Daemons übernehmen die Verbindung und der Zero am Rover steuert die Schrittmotortreiber.

Ergebnis: Das ging sehr schnell und funktioniert super! Die Übertragung verzögert nicht weiter (langsam ist nicht die Steuerung, sondern die Logic der Beschleunigungsrampen).

Aufbau Versuch 5:

Versuchsweise wird die Antriebsspannung für die Schrittmotore auf 24V angehoben. Bei hohen Geschwindigkeiten bringt ein Schrittmotor mehr Leistung bei höherer Spannung.
Dazu wird provisorisch ein zweiter Bleigelakku auf das Gefährt montiert.

Ergebnis: Die Wirkung ist überschaubar. Der Antrieb hat etwas mehr Anzug, die Höchstgeschwindigkeit ist aber kaum höher (zumal auch einiges an Gewicht drauf gekommen ist). Leider habe ich bei einem „Auffahrunfall“ den Aufbau ziemlich zerlegt.
Vorher hat das Ding aber richtig fies ausgesehen, Mad Max war da eher unterdimensioniert.

Fazit:

An sich ist das System nach etwas Feintuning sicherlich verwendbar, aber ineffizient.
Der Akku ist zu fett, die Ansteuerung zu träge und der Antrieb braucht auch noch Aufmerksamkeit im Design. Der Raspberry verbrennt auch ordentlich Strom und eine komplette Steuerung ist in Python auch nicht richtig angesiedelt.
Bei passender Gelegenheit wird ein neuer Aufbau gemacht, dann aber mit Arduino und C/C++ und komplett gedruckten Rahmen/Aufbau.

Probleme:

Das Hauptproblem ist die träge Steuerung aufgrund der zu flachen Beschleunigungsrampen und der Trägheit des Modells (zu schwer) sowie zeitliche Unverbindlichkeit von Python-Code.

Die komplette Steuerung der Schrittmotortreiber per Python und entsprechender Lib war schlichtweg zu unpräzise und führte ständig zu späten Signalen an den Treiber, was insgesamt zu unrunden Schrittmotorlauf führte.
Nach der Umstellung der Steuerung auf den Daemon zur Schrittmotorsteuerung war das Ansprechverhalten erheblich präziser, aber immer noch nicht ideal. Vor allen, da ich die Rampen bei der Ansteuerung ständig zu flach gehalten habe um Schrittverluste zu vermeiden.

Der Direktantrieb am Motor ist zu schwach für das Gewicht, ohne Umsetzung scheitert das Gefährt schon am Teppich. Mit 1:3 Riemenumsetzung war aber einiges an Reserve drin.
Allerding fehlen im Aufbau noch eine Spannrolle, um den Riemen ausreichend sicher an den Rollen zu halten.

Der Bleigelakku ist erwartungsgemäß schwer und benötigt viel Platz. Für den Versuchsaufbau ok, für eine echte Lösung aber keine Option.

Der provisorische Aufbau ist nicht gerade stabil und gegenüber harten Aufprall zu wenig haltbar. Beim Versuch mit 2 Akkus (24V Antriebsspannung) ist beim Aufprall der ganze Akkusatz nach vorne gerutscht und hat den Rover sauber zerspant. Naja, war ohnehin neu zu machen…

Komponenten:
Rechner: Raspberry Zero und Pi 3B+
Schrittmotor: NEMA17 (17HD48002H-22B)
Treiber: TB6000
SW: Python
Bleigel-Akku 12V
PS3 Controller

Überlegungen:
Raspberry:
Einfach meine erste Entwicklungsplattform.
Python: Die von mir am meisten genutzte Programmiersprache mit nativen Libs für DIY-Bauteilen und mit JetBrains PyCharm eine passende IDE.

Schäden:
– Mehrere Dellen an Möbeln wegen der Latenz beim Bremsen und Lenken.
– Zerlegte Halter nach Bremscrash beim Erstversuch mit 2 Bleiakkus.

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