Drohnenselbstbau – Grundlagen und Design

In einem anderen Artikel beschreibe ich die Erfahrungen mit dem Selbstbau einer Drohne. Hier möchte ich ergänzend dazu zu grundsätzlichen Fragen zum Thema Drohnenbau und Flugbetrieb schreiben.

Wenn man mit dem Thema startet, muss man sich (ohne Anspruch auf Vollständigkeit) mindestens mit folgenden Themen auseinandersetzen:

  • Rechtliche Bestimmungen zum Flugbetrieb
  • Welche Art von Drohne soll’s den werden
  • Design und Auslegung des Modells

Rechtliche Bestimmungen zum Flugbetrieb

In Deutschland gilt die neue Drohnen-Verordnung. Gleich als Warnung vorab: Die nachfolgenden Info’s sind nicht vollumfänglich, eine Einarbeitung in alle Aspekte der kompletten Regelung ist nicht zu vermeiden und auch gefordert (u.a. durch den Kenntnisnachweis).

In der Verordnung ist unter anderem festgelegt, das Drohnen
o ab 250g einen Kenntnisnachweis des Piloten erfordert, eine feuersichere Halterplakette gut sichtbar am Modell und eine geeignete Haftpflichtversicherung
o ab 5000g zusätzlich eine Aufstiegserlaubnis erforderlich ist.

Ergänzend dazu sind Regeln zur maximalen Flughöhe, zu Flugverbotszonen und zu generellen Verhaltensweisen speziell bei Kamerabetrieb und ähnliche Fragen zu beachten. Wichtig ist auch, das Flüge außerhalb der eigenen Sichtreichweite nicht zulässig sind. FPV-Flug (First Person View) erfordert zusätzlichen einen Feldbeobachter zur Unterstützung, da der Pilot alleine nicht in der Lage ist das komplette Flugfeld zu übersehen.

Später im Design sind auch noch zusätzlich die Vorgaben zu verwendeten Funkfrequenzen und maximalen Sendeleistungen zu beachten. Dies ist vor allem für FPV-Komponenten und Telemetrie-Module interessant.

Das BMVI (Bundesministerium für Verkehr und Digitale Infrastruktur) hat hier einen netten Flyer und Informationen.
Ebenfalls anzuraten ist als Informationsquelle, darüber hinaus auch für den Kenntnisnachweis und die zumeist erforderliche spezielle Versicherung, der DMFV (Deutscher Modellflieger Verband e.V.). Das Angebot dort erlaubt es die notwendigen Voraussetzungen für die meisten Fälle mit überschaubaren Kosten zu erfüllen.

Welche Art von Drohne soll’s den werden

Grundsätzlich würde ich zwischen 3 Arten von Drohnen unterscheiden:

  1. Racing-Drohnen
    • Kompakt und leicht gebaut
    • Zumeist Quadrocopter 
    • Wenig bis kaum Hilfe bei der Steuerung, dafür sehr agil
    • Üblicherweise mit FPV (First Person View)
    • Sehr leistungsstarke Motoren und kompakte, schnelldrehende Propeller
    • Meist begrenzte Flugzeit <10 Minuten, da Akkukapazität zugunsten Gewichtsersparnis begrenzt wird.
  2. Kamera-Drohnen
    • Eher groß gebaut um ausreichend Platz für alle Bestandteile zu bieten und für eine gewisse Stabilität in der Luft
    • Zumeist Quadrocopter oder Hexacopter, aber auch Octacoper oder andere Varianten.
    • Weitreichende Unterstützung in der Stabilisierung bis zu autonomen Flug
    • Ausgerüstet mit Gimbal und Kamera für Flugaufnahmen
    • Eher auf Effizienz ausgelegte Motoren mit großen, langsamdrehenden Propellern.
    • Akkuauslegung bestimmt Flugzeit, viele Modelle mit mehrern Akkupacks für lange Aufnahmezeiten.
  3. Agrar-, Transport- oder Militärische Drohnen
    • Je nach Anwendungsfall völlig verschieden, aber für gewöhnlich jenseits der 5Kg-Grenze und jenseits des normalen Anwendungsfalls von Privatfliegern.

Im Regelfall muss man sich also zwischen Racing-Drohne oder Kamera-Drohne entscheiden, da die Designvorgaben jeweils widersprüchlich sind.

Design und Auslegung des Modells

Für den Bereich der Racing-Drohnen kann ich nur wenig sagen, da ich das Segment für mich nicht interessant finde. Bei den Kamera-Drohnen biete ich mal die von mir gesammelten Informationen an, wieder ohne Anspruch auf Vollständigkeit:

Die Quadrocopter-Konfiguration mit 4 Motoren ist wohl die häufigste Einstiegsvariante und schon recht günstig zu bekommen (F500 oder S500 Rahmen). Wenn man mehr Schub benötigt sind Hexacopter mit 6 Motoren ebenfalls noch gut zu finanzieren (F550 oder S550 Rahmen). Der Octacopter soll im Flugverhalten besser sein, ist aber preislich erheblich höher angesiedelt und überschreitet auch mal schnell die magischen 5 Kg Modellgewicht.
Speziellere Varianten mit 3 oder nur 1 Motor und gegensätzlich montierte Motoren kann ich nur anmerken, aber wenig sinnvolles dazu sagen.

Grundsätzlich gilt die Faustregel, das die Motoren und Propeller so ausgelegen sind, das die Motoren/Propeller-Kombi etwa doppelt so viel Schub erzeugt wie das Modell Gewicht hat. Dann ist von einem für den Kamerabetrieb gut ausgelegten System auszugehen.
Das ist gar nicht so einfach, weil diese Information gar nicht so selbstverständlich dokumentiert wird und sehr oft empirisch durch Teststände ermittelt werden.
Motorenhersteller geben aber oft Empfehlungen für die Propeller an, was die Eingrenzung schon mal erleichtert.
Beispiel: Für mein System mit A2212 KV1000 Motoren werden Propeller vom Typ 1047 empfohlen (10″x4,7″). Mit 3S Akkus erreicht man ca. 800g Schub pro Motor. Das ergibt einen Gesamtschub von 3200g und damit ein empfohlenes Modellgewicht von max. 1600g.
Wichtig ist aus meiner Sicht die Klarstellung, das größere, stärkere, schnellere (und teurere) Motoren nicht notwendigerweise die bessere Wahl sind. Je nach Bedarf sogar eher die falsche.

Zur Ansteuerung der bürstenlosen Motoren braucht es sogenannte ESCs.
Hier sollte die Leistung mit Abstand zum Bedarf des Motors dimensioniert werden, um einen Spannungseinbruch bei kurzzeitiger Überlastung zu vermeiden. Bei den Kosten machen 10A Reserve kaum was aus, ein Absturz aber schon. Mein Modell hat ESCs mit 30A, der Motor benötigt ca. 10A. Kleinere Dimensionierung macht hier (bei China-Einkauf) nur wenige Euros in Summe aus und kann so vernachlässigt werden. Anders kann dies natürlich bei der Qualität der Bauteile aussehen, das muss jeder für sich entscheiden.

Zur Stromverteilung bietet sich eine fertige Verteilerplatine aus. Da werden dann die Kabel der ESCs angelötet zur sicheren Stromversorgung. In manchen Rahmen ist ein solcher Verteiler sogar in den Platten integriert. Manche Module bieten dazu stabilisierte Spannungen von 5V und 12V an (5V gibt es aber auch von manchen ESCs).

Kameradrohnen haben meist einen Flugrechner eingebaut zur Steuerungsunterstützung bis zum autonomen Flug. Hier muss man sich etwas reinarbeiten. Ich bin mit Ardupilot und APM2.8 gestartet, aktuell ist eher ein Pixhawk. Alternativen gibt es natürlich massig. Das diese Komponente für sich recht komplex werden kann, gehe ich darauf mal in einem eigenen Artikel ein.

Bei der Fernsteuerung ist auch Auswahl angesagt. Gängige Marken und weniger bekannte Hersteller stehen oft am Anfang gleichwertig nebeneinander. Wenn es aber an die Leistungsgrenze geht oder einfach um andere Erfahrungsträger (z.B. Trainer/Schülerbetrieb) lohnt sich eine Markenanlage.
Ich benutze derzeit eine FlySky FS-TM10 10-Kanal Anlage. Laut Foren ist die Leistung Ok und das Set ist mit Empfänger bereits ab 40€ zu bekommen. Da kann man später auch mal Umsteigen ohne sich zu ärgern. Nachteil ist aber die schlechte Doku (-keine!-), ebensolcher Herstellersupport und im Vergleich wenig Benutzererfahrung in Foren. Man kann halt nicht alles haben 🙂

Akku definiert sich erst mal an der Anzahl der Zellen (xS, also x Zellen in Serie). Je höher, deste mehr Spannung im System und zumeist auch mehr Leistung. Oft geht das dann aber mit mehr Gewicht, geringerer Effizienz und kürzerer Flugzeit einher. Gängig sind 3S und 4S.
Bei den Racing-Drohnen geht das noch höher, wird aber dann auch wieder irgendwann problematisch (Feuergefahr,…). Teuer sowiso.
Als zweite Variable gibt es die Kapazität. Typische Konfigurationen bewegen sich im Bereich 1500 mAh bis 5000 mAh, Ausnahmen bestätigen die Regel.
Als letztes ist hier die Strombelastbarkeit zu nenenn (xC, also x * die Kapazität). Ein 100C-Akku mit 1500 mAh kann also maximal 150A liefern. Der Wert sollte mit einem gewissen Abstand zum Bedarf des Models dimensioniert werden, sonst bricht einem die Spannung bei härten Flugmanövern weg und das Modell stürzt ab (Brown-Out).
In meinem Modell benötige ich ~10A pro Motor, also ~40A. Ein 1500mAh Akku sollte mit Reserve mindestens 40C aufweisen (60A). Weil es preislich nicht so richtig viel ausmacht, nutze ich allerdings 100C bei 1,5 Ah und 60C bei 5 Ah, also erheblich mehr Reserve. 

Für den Kamerabetrieb braucht es natürlich eine Kamera. Hier werden bei den Selbstbauversionen gerne Action Kameras verwendet. Auflösungen bis 4K sind schon günstig drin, Full HD Standard, die Teile sind klein und relativ leicht. Manche biete WLAN-Streaming für kurze Distanzen, praktisch alle Speicherkarten. Action Cams haben meist 120° Sichtwinkel und damit eine leicht verzerrte Optik. Die Stromversorgung ist integriert und typischerweise mit >1h mehr als ausreichend auch für ausgedehnte Flüge. Hier lohnt sich die Recherche in einschlägigen Foren zu Erfahrungen von Besitzern und manche Vergleichsvideos in Youtube. Oft unterscheiden sich die Fähigkeiten in Lichtverhältnissen, manche Schwächen von günstigeren Modellen müssen auch nicht immer für den eigenen Anwendungsfall relevant sein.
Damit das ganze für Betrachter angenehmer wird, kann die Kamera in einen Gimbal montiert werden. Der gleicht Bewegungen der Drohne in 2 oder 3 Achsen aus und bietet üblicherweise auch die Option die Achsen zusätzlich per Fernsteuerung mit freien Kanälen entsprechend auszurichten.
Normalerweise ist (mindestens) das ganze Kamerasystem schwingend montiert um die im System vorhandenen Schwingungen vom Video zu entkoppeln.

Quadrocopter – Summbrummsel – Phase 2

Der im letzten Jahr provisorisch aufgebaute Quadrocopter hat sich nun erheblich weiter entwickelt. Grund genug mal wieder was drüber zu schreiben und die aktuellen Erfahrungen zu teilen. Fertig ist das Teil natürlich immer noch nicht, wird es aber wohl auch ...

FPV – Der erste Kontakt

Als eine der nächsten Erweiterungen des Quadrocopters steht ein FPV (First Person View)-System an. Hier meine ersten Erfahrungen mit einem Minimalsystem (ohne Drohne).Projekt: Quadrocopter Kontakt: Boris Dirnfeldner Link: - eigenes Projekt -Beim reinlesen in das Thema Drohnenflug finden man sehr ...

Drohnenselbstbau – Grundlagen und Design

In einem anderen Artikel beschreibe ich die Erfahrungen mit dem Selbstbau einer Drohne. Hier möchte ich ergänzend dazu zu grundsätzlichen Fragen zum Thema Drohnenbau und Flugbetrieb schreiben.Wenn man mit dem Thema startet, muss man sich (ohne Anspruch auf Vollständigkeit) mindestens ...

Quadrocopter – Summbrummsel – Phase 1

Als langjähriger RC-Modellhubschrauber Fan konnte ich mich dem Charm der diversen Varianten von Drohnen kaum lange verschließen. Nach etwas rumspielen mit einer Minidrohne ist nun eine richtige Kameradrohne in Arbeit. Der Artikel wird immer wieder mit Nachfolgeartikeln ergänzt sobald sich ...

Quadrocopter – Summbrummsel – Phase 1

Als langjähriger RC-Modellhubschrauber Fan konnte ich mich dem Charm der diversen Varianten von Drohnen kaum lange verschließen. Nach etwas rumspielen mit einer Minidrohne ist nun eine richtige Kameradrohne in Arbeit. Der Artikel wird immer wieder mit Nachfolgeartikeln ergänzt sobald sich ein neuer Stand ergibt.

Projekt: Quadrocopter

Kontakt: Boris Dirnfeldner

Link: – eigenes Projekt –

Gestartet habe ich mit einer Minimalkonfiguration, also den Bestandteilen die unbedingt zum Fliegen erforderlich sind. Dazu gehört der Rahmen, Motore, ESCs, Flugrechner, Empfänger und kleiner Akku mit Stromverteilung. Alles andere wird erst später dran gebaut.
Der erste Stand ist erstmal provisorisch zusammengebastelt. Die Teile sind auch nur provisorisch befestigt um die Flugeigenschaften zu testen. Nachdem also alles irgendwie zusammen hält, raus auf die Wiese zum testen.

Das Teil liegt sehr stabil in der Luft (erstmal ohne GPS) und reagiert noch angenehm agil auf Steuerungsbefehle (ist auch noch sehr leicht). Erst mal wird nur im „Stabilize“-Mode geflogen (Roll und Pitch-Achsen werden automatisch ausgerichtet wenn keine Knüppelvorgabe erfolgt), damit auch keine Höhen- und Positionskontrolle. Die Fernsteuerung ist auch noch nicht für Mode-Änderungen etc. eingerichtet.

Von der Lautstärke ist die Drohne angenehm leise (Zitat Nachbar: „Wie mein Rasenmähroboter, nur etwas höher in der Tonlage“). Im Radius von 5 Metern deutlich zu hören, danach aber sehr dezent auch wegen der tiefen „Tonlage“.
Bei heftigeren Ruderbewegungen und starken Bremsen „schrappen“ die Propeller etwas, da kommt das Nylon-Karbon-Gemisch wohl an seine Grenzen.

Es war aber schon einiges an Vorarbeit und Erfahrung zu machen, bis das Teil endlich geflogen ist (und auch in der Luft blieb).

Zum einen mussten erst mal die ESCs kalibriert werden. Ansonsten ist das Regelverhalten des Flugrechners schwierig (weil die Motoren unterschiedlich früh starten und die maximale Leistung erreichen; der Flugrechner muss dann manuell nachregeln). Die Signalisierung per Audio ist am Anfang gewöhnungsbedürftig, dann aber sehr intuitiv.

Die Kalibrierung des Kompass- und Lagesensors ist auch anzuraten (einmal reicht dann aber normalerweise).

Sehr zu empfehlen ist aber die korrekten Einstellungen der Achsenrichtungen. Beim ersten vorsichtigen Versuch im Büro hat meine Drohne gleich mal einen Salto vorwärts gemacht weil ich hier eine Achse in die falsche Richtung eingerichtet habe.

Es lohnt sich auch die Propellerbefestigung sehr gründlich zu prüfen. Auch hier konnte ich einen freifliegenden Propeller im Büro genießen weil einer nicht fest genug angezogen war. Selbstsichernde Versionen gibt es leider für die A2212 Motoren nicht.

Der Flugrechner ist leider nicht mehr in der Liste der unterstützten Systeme von ArduPilot, tut aber in der letzten unterstützten Version (3.2.1) seinen Dienst ohne Probleme. Wenn ich irgendwann mal eine neuere Version haben will, muss das Teil ersetzt werden. Vorerst war es ein billiger Einstieg und ist definitiv gut genug.

Das Stromverteilermodul hat ein BEC für 5V und 12V. An sich gut, leider haben auch die ESC BECs für 5V und über Flugrechner und RC-Empfänger wird alles miteinander verbunden. Ich habe über diverse Foren gelernt, das dies die Regler der einzelnen BECs ziemlich fordert und Probleme verursachen kann. Vorerst sind die ESCs mal abgeklemmt.

Das Überwachungsmodul für den Akku ist toll. Am Display kann man die Gesamtspannung und die Spannungen der einzelnen Zellen sauber ablesen.
Wenn die Spannung unter einen einstellbaren Schwellwert sinkt, gibt das Teil über 2 Piezo-Beeper lautstark Alarm.

Es lohnt sich auch die Anschaffung des Beepers und der beiden Statusleds (für Arm-Status bzw. GPS-Fix). Das würde den Start vereinfachen, gerade wenn es Probleme gegeben hat. Ist bestellt für die nächste Version…

Komponenten:
Frame: S500
ESC: ReadytoSky 30A SimonK (4x)
Motors: A2212 KV1000 (4x)
RC Sender: FlySky FS-TM10
RC Empfänger: FlySky FS-IA10B
Flugrechner: APM2.8
Firmware: Ardupilot 3.2.1

Überlegungen:
Quadrocopter: Standardkonfig, entsprechende Frames sind billig zu bekommen und sehr ausgereift. Später evtl. Hexacopter wenn mehr Last angehoben werden muss. Octacopter wäre schön, ist aber zu teuer.
APM 2.8: Nicht mehr für neue Versionen von Ardupilot unterstützt, aber sehr günstig zu bekommen und mehr als ausreichend für die meisten Ansprüche.
A2212 Motore und 1047 Propeller: Beim S500 Eigenbau eine häufig genutzte Konfiguration und recht günstig zu bekommen.

Schäden:
– Ein Propeller beim Salto.
– Einige Nerven bis ich das Prozedere zur Einrichtung endlich richtig durchdrungen hatte.

Quadrocopter – Summbrummsel – Phase 2

Der im letzten Jahr provisorisch aufgebaute Quadrocopter hat sich nun erheblich weiter entwickelt. Grund genug mal wieder was drüber zu schreiben und die aktuellen Erfahrungen zu teilen. Fertig ist das Teil natürlich immer noch nicht, wird es aber wohl auch ...

FPV – Der erste Kontakt

Als eine der nächsten Erweiterungen des Quadrocopters steht ein FPV (First Person View)-System an. Hier meine ersten Erfahrungen mit einem Minimalsystem (ohne Drohne).Projekt: Quadrocopter Kontakt: Boris Dirnfeldner Link: - eigenes Projekt -Beim reinlesen in das Thema Drohnenflug finden man sehr ...

Drohnenselbstbau – Grundlagen und Design

In einem anderen Artikel beschreibe ich die Erfahrungen mit dem Selbstbau einer Drohne. Hier möchte ich ergänzend dazu zu grundsätzlichen Fragen zum Thema Drohnenbau und Flugbetrieb schreiben.Wenn man mit dem Thema startet, muss man sich (ohne Anspruch auf Vollständigkeit) mindestens ...

Quadrocopter – Summbrummsel – Phase 1

Als langjähriger RC-Modellhubschrauber Fan konnte ich mich dem Charm der diversen Varianten von Drohnen kaum lange verschließen. Nach etwas rumspielen mit einer Minidrohne ist nun eine richtige Kameradrohne in Arbeit. Der Artikel wird immer wieder mit Nachfolgeartikeln ergänzt sobald sich ...

Beetbewässerung – Gieskanne des Teufels – Phase 1

Ein Anspruch an meine Projekte ist das es ein Ergebnis gibt, das in irgend einer Weise praktischen Nutzen bringt (oder einfach Laune macht). Da am Haus mehrere Hochbeete beständig nach Wasser brüllen war eine automatische Bewässerung ein naheliegendes Thema für einen Eigenbau.

Projekt: Beetbewässerung

Kontakt: Boris Dirnfeldner

Link: – eigenes Projekt –

Leider ist hier eine Menge Grundlagenarbeit in die Basissteuerung geflossen und auch in den Aufbau bzw. der Peripherie, was den Produktivbetrieb am Ende doch empfindlich verzögert hat. Dazu aber später mehr.

Basis ist ein Arduino Mega 2560 board mit RTC-Modul, SD-Card-Modul, OLED Display, WLAN-Modul und ein 8-fach Relais-Modul.

Über die Relais werden derzeit 5 Magnetventile angesteuert (3 Relais in Reserve).

Die Stromversorgung ist gelöst über ein 230V Schaltnetzteil auf 12V (Spannung für die Magnetventile) und ein Konverter auf 5V. Das Arduino-Board liefert noch 3,3V.

Aufgebaut ist das ganze auf einer per 3D-Druck aufgebauten Trägerplatte aus PLA, montiert in einen IP65 Gehäuse am ersten Beet.

Der Wasserkreislauf besteht auch einer Wasserzuführung (1/2″-Gartenschlauch), die über Rohrfittinge in die 5 Magnetventile geleitet wird (parallel) und von dort für jedes Beet wieder per 1/2″ Gartenschlauch und Y-Adapter an 5/8mm Schlauch mit Tropfern weiterverteilt wird. Pro Beet sind je 10 Tropferstellen an 2 Strängen vorgesehen.

Vorgesehen sind 2 Betriebsmodis:
o Zeitbasierende Bewässerung: Pro Beet wir eine feste Zeit das Magnetventil geöffnet und dann wieder geschlossen.
o Mengenbasierende Bewässerung: Am Eingang befindet sich ein Mengenzähler, der Betrieb erfolgt statt über Zeit über Ticks des Zählers.
Für beide Modis sind Maximalwerte implementiert und mit dem Mengenzähler auch Plausibilitätsprüfungen.

Im System sind pro Tag 24 Slots vorgesehen, die jeweils eine Bewässerung auslösen können. Dabei wird immer nur ein Magnetventil geöffnet um einen Abfall des Wasserdrucks zu unterbinden.

Weiterhin sind pro Beet 2 kapazitive Feuchtigkeitsmesser vorgesehen, die Bewässerungen anteilig zum Feuchtegrad im Beet reduzieren oder unterbinden können.

Seitlich ist ein Netzschalter für 230V vorgesehen und auf der anderen Seite 2 Taster zur Benutzerführung (Switch der Anzeige, Manuelle Auslösung der Bewässerung).

Intern ist die Software in Tasks organisiert, die über einen Scheduler zeitbasiert angesteuert wird und sich über Variablen aussteuert (ähnlich einer SPS).

Per USB ist auch noch eine Kommandozeilensteuerung eingebaut, die manuelle Steuerung der Relais und ein Paar andere Kommandos unterstützt.

Probleme und Herausforderungen:

Das Projekt war gleichzeitig an vielen Stellen Erfahrungsgewinn.

Zum einen wurde hier meine Basisumgebung zur Ansteuerung diverser Sensoren, der Aktoren, der Scheduler und allem anderen aufgebaut und mehrfach überarbeitet. Obgleich die Basislogik schnell definiert ist, war die Implementierung dann im Detail recht umfangreich und brauchte mehrere Runden von Idee – Konzept – Entwicklung – Test – Kopfschmerz – Heureka – Nochmaal!
Vor allen, da ich From-the-Scratch nur auf Libs aufgesetzt habe mit dem Ziel für mich hier eine allgemeine Code-Basis zu schaffen.

Der Aufbau im Gehäuse hat wiederum seine Zeit gefordert. Zum einen soll das Ding ja auch länger arbeiten und Leben und zum anderen, weil mit 230V gearbeitet wird. Sorgfalt war hier angesagt und einige Stunden Arbeit damit.

Der Wasserkreislauf ist im Bereich Lebenserfahrung besonders wertvoll. Ich habe noch nie so ausgeprägte und vielfältige Schimpfwörter beim dichten von Leitungen und Anschlüssen benötigt und verwendet. Besonders die tollen Adapter von 1/2″ auf 5/8mm für die Endverschlauchung waren eine echte Freude (Kombiadapter 1/2″ – 8/11mm – 5/8mm, letztere Verbindung ging bei Druck öfter mal auf und hatte Badespaß zur Folge). Zumindest konnte ich mich so von der Dichtigkeit des Gehäuses überzeugen, das war mehr als einmal mit erheblichen Wassermengen und direkten Wasserstrahl begossen worden.
Insgesamt war auch die Auslegung des Systems ein Problem. Wenig Druck führte dazu, das an den letzten Dripperköpfen kein Wasser mehr angekommen ist. Zuviel Druck belastete die Kupplungen (und vor allen den Adapter) derart, das Undichtigkeiten oder Ausfall die Folge war.
Auch waren die Dripperköpfe auf Bodenniveau „gelegt“. Nachdem da einige Pflanzen drum rum und drüber gewachsen waren und ein Paar gärtnerische Aktivitäten gelaufen sind, waren einige unter der Erde vergraben und damit nicht mehr effektiv. Die nächste Generation wird oberirdisch auf Plastikpfählen das Problem lösen.

Die Elektroniker unter Euch haben beim Schaltnetzteil (chinesisches Fabrikat) sicher schon in sich hinein gelächelt. Lustigerweise ist das Netzteil offenbar so unsauber in der Ausgangsseite, das der Mengensensor damit ständig Bewegung im Wasserkreislauf detektiert hat (mit USB als Versorgung läuft der einwandfrei). Da wird wohl ein Glättkondensator und/oder ein besseres Netzteil fällig.

Ursprünglich war ich auch mit einem Arduino Uno gestartet, bis das SD-Modul dazu gekommen ist. Der Zugriff auf die Karte erfolgt in 512 Byte-Blöcken, wovon einer komplett ins RAM geladen werden muss. Da der Uno nur 2K in Summe hat, wird es da sehr eng (zu eng). Mit den kapazitiven Sensoren (die Analog-Input brauchen), wäre es auf dem Uno ohnehin zu eng geworden.

Das RTC-Modul wurde auch ausgetauscht. Die erste Version (DS1307) ist tatsächlich erheblich weggedriftet und faktisch unbrauchbar. Der Effekt war umso stärker, je öfter auf das Modul zugegriffen wurde. Das neue Modul hat das Problem nicht mehr und dazu eine aufladbare Batterie.

Beim WLAN war’s auch nicht langweilig. Gestartet mit einem (ESP8266) und der dazu passenden Library musste ich nach einigen Versuchen feststellen, das die Stabilität erheblich zu mies war um damit irgendwas zu machen, schon gar nicht per MQTT zu übertragen. Der Speicherverbrauch der Library war ebenfalls inakzeptabel.
Der Umstieg auf ESP-Link und El-Client war hier eine erhebliche Verbesserung, so das Senden nun sicher funktioniert. Leider hat die Lösung beim Empfang von großen MQTT-Messages auch einen Bug, was den Teil wieder unbrauchbar macht.
Wenn das wirklich mal komplett laufen muss, wird hier wohl eine eigene Version erforderlich oder ein Umstieg auf eine andere Plattform. z.B. ESP32.

Da die vielen Themen erheblich mehr Zeit als ursprünglich geplant gefressen haben, wurde die Funktionalität erst mal auf reinen Zeitbetrieb ohne Feuchtesensoren und Mengenmesser verkleinert (im Code, Verkabelung und Gehäusedesign aber schon vorhanden).

Das alles zusammen brauchte der Aufbau des System derart viel meiner (Teil-)Zeit, das ich erst im Spätherbst damit final ans Beet gekommen bin und außer ein Paar Testläufen nicht mehr viel Betrieb drin war.

Komponenten:
Rechner: Arduino Mega 2560
SD: Micro SD Card Module SPI
RTC: DS3231
WLAN: ESP-01S
OLED: SSD1306 0,96″ IIC
SW: Arduino UI

Überlegungen:
Arduino Mega:
Günstige Nachbauten verfügbar, stabil und massig I/O Leistungen. Im Vergleich zum Uno auch ausreichend Speicher

Schäden:
– Mehrmals Nass geworden weil wieder mal ein Schlauch abgegangen ist.

– Rücken beim Verlegen der Schläuche und Kabel (im Zuge einer generellen Umgestaltung der Beetumrandung).

Nachtrag zum Saisonende 2019:

Wie gesagt ist das Teil nicht in Regelbetrieb gegangen. Für den Winter ist das System wieder abgebaut und geprüft worden. Ich kann weiterhin die Dichte des Gehäuses positiv bewerten (keine Feuchtigkeit oder Kondenswasser im System). Auch gegen Erde und anderen Dreck ist das Teil immun.

Das Schlauchmaterial hat auch kein Problem und ist weiterhin dicht.

Die Dripperköpfe sind wohl nicht besonders sonnenfest und deutlich ausgebleicht.
Das wird wohl als Verbrauchsmaterial zu werten sein. In der nächsten Saison sind ohnehin andere geplant.

Die Kabel zu den Magnetventilen waren nicht extra verpackt bzw. geschützt und haben auch etwas Farbe verloren. Ansonsten zwar ok, werden aber in der nächsten Saison vor Sonne geschützt.

 

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

Smartclock – dem die Stunde schlägt.

Im Zuge der Konzeptarbeiten an der Heimautomatisierung zeigt sich immer wieder der Bedarf an einem Display bzw. einer Signalisierung allgemein. Da ich gerade Bock drauf hatte eine Uhr zu bauen, muss diese auch für den ersten Versuch dazu herhalten. 

Projekt: Smartclock

Kontakt: Boris Dirnfeldner

Link: – eigenes Projekt –

Mir haben diese Leuchtanzeigen auf Basis von WS2812 schon immer gefallen, zumal die Dinger ja auch mit so wenig Drahtverhau auskommen (VCC, GND und Signal). Die Ansteuerung erfolgt über ein serielles Protokoll (Eindraht) und fertige Libs für Arduino gibt es dazu auch. Nachdem ich einen Leuchtring mit 60 LEDs gefunden hatte, war klar das dies eine Uhr werden musste.

Anforderungen:

o Anzeige der Uhrzeit analog über den Leuchtring.
o Anzeige von Datum und Uhrzeit über LED-Segmentanzeigen digital
o Signalisierung von Zählerständen, über MQTT-Nachrichten im System zentral verteilt und von dort auch bezogen. Rückwärtszähler sollten bei <60 Sekunden am Ring präsent angezeigt werden.
o Signalisierung von Events über MQTT, die über „Flashen“ am Ring dargestellt werden. Dabei soll es verschiedene Kritikalitäten geben, z.B. Rot für Alarme, Gelb z.B. für Türklingel etc.

Design:

Der Zeitgeber ist ein RTC vom Typ DS3231. Als Controller wird ein Arduino verwendet, der Analogring besteht aus 60 x WS2812 auf vier Platinen (je ein Viertelkreis). Die Digitalanzeigen sind mit TM1637 Display-Modulen aufgebaut die auch mit einer 2-Drahtverbindung seriell angesteuert werden (Signal + CLK).
Die Anbindung an den MQTT-Server erfolgt über einen ESP-01S und ESP-Link.

Aufbau und Inbetriebnahme:

Der RTC-Code ist kein Problem, auch die Ansteuerung eines TM1637 nicht. Nachdem die ersten Teile richtig funktionieren wird alles mal fliegend verdrahtet.
Und siehe da, es geht gar nix mehr.

Es zeigt sich recht schnell das die Stromversorgung mit Arduino für die Anzeige nicht mehr reicht, also die Stromversorgung separat aufbauen und schon ist alles gut.

Der Ring erfordert erstmal Lötarbeit damit aus den vier Teilen auch ein Ring wird (und das kann ich so gar nicht gut). Naja, irgendwie halten die Teile (mehr aus Mitleid) zusammen.
Die Ansteuerung ist ziemlich einfach, nur die Leuchtkraft der Module hat mich überrascht. Beim ersten Versuch (mit externer Stromversorgung, ich habe mit den TMs gelernt) war ich erst mal blind und hatte den Ring wortwörtlich im Auge eingebrannt am nachleuchten. Die Lib startet per Default alles in voller Leistung in Weiß, und das ist dann Abends im Zimmer hell!
Bei den nächsten Versuchen (mit erheblich weniger Leistung per Parameter) ist dann auch alles gut. Nach etwas Kodierarbeit zeigt sich auch eine uhrenähnliche Anzeige.

Jetzt kommen die TMs wieder dran und bekommen auch Code zur Anzeige von Datum und Zeit. Auch die Module lassen sich in der Helligkeit parametrisieren (was dann auch passiert).

Nachdem das alles läuft (die Uhr an sich ist damit fertig) geht es an die Netzwerkverbindung und die Signalisierung. Mit dem Ring sind einfache Blinksignale kein Problem, ein Satz von Funktionen habe ich schnell fertig.

Der ESP-01s ist auch schnell verbunden und die ESP-Link Firmware in Verbindung mit EL-Client Library bietet mir eine komfortable Anbindung an den MQTT-Server.
Leider zeigt sich hier ein übler Bug in der Firmware des ESP, der beim Empfang längerer MQTT-Nachrichten leider versagt und die Meldung verschluckt.
Das Problem hat leider auch ein anderes Problem erwischt (Beetbewässerung) und kann nicht zeitnah gelöst werden. Damit bekomme ich leider die Anbindung nicht zuverlässig hin.

Ich spiele mich noch etwas mit der Anzeige (mache z.B. Leuchtpunkte für die 5-Minuten-Markierung) und baue den Code für meine Library um, will aber das Teil so nicht fertigmachen.
Da ich etwas Zeitdruck an anderen Baustellen habe, bleibt der fertige Aufbau noch aus.

Fazit:

Die Uhr an sich läuft, der Aufbau in ein ansehnliches Gehäuse ist erstmal noch vertagt bis ich das Netzwerkthema unter Kontrolle habe. Sieht sehr danach aus als würde ich den Arduino ersetzen gegen was mit integrierten WLAN (z.B. ESP32).
Dann kommt auch die Zähleranzeige dazu und vermutlich ein Drehgeber zu Eingaben am Gerät. Vielleicht kommt ja noch ein „richtiges“ Display rein, mal sehen. Vorerst geht es erst mal mit anderen Dingen weiter und dem Design vom Gehäuse.

Komponenten:
RTC DS3231 Echtzeituhr
TM1637 Display Module
WS2812 RGB-Ring (60)
Arduino Uno (Clone)
ESP01S WLAN-Modul
Schaltnetzteil 230V/5V
MQTT-Server im Netz

Überlegungen:
Da im Haus keine Alexa wohnt, aber ständig langlaufende Timer gebraucht werden, wäre doch eine relativ intelligente Uhr gar nicht so doof.

Schäden:
– Einmal Geblitzdingst beim ersten Start des Leuchtrings.
– Wegen MQTT-Problem ist die Uhr noch nicht smart.

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