Projekte

Ich habe im Laufe der Jahre viele verschiedene Dinge geschaffen oder war an ihnen beteiligt. Manche nur zum Spaß, manche für einen bestimmten Zweck. Diejenigen, die ich gerne mit der Welt teilen möchte, sind unten aufgeführt.

Power-Management für den ESP32-S3 basierten Lehrroboter Dezibot4 (2025) Link zu Überschrift

Als Teil meiner Masterarbeit habe ich den Strombedarf des Dezibot4 analysiert. Der Dezibot4 ist ein an der HTWK Leipzig entwickelter Lehrroboter auf Grundlage des ESP32-S3-Mikrocontrollers.

Ziel war es, zuvor beobachtete Instabilitäten aufgrund der begrenzten Leistungsfähigkeit der Stromversorgung zu vermeiden. Die Stromversorgung erfolgt durch eine wiederaufladbare Knopfzelle, welche in Lastspitzen nicht genügend Leistung bereitstellen kann. Da auf dem Roboter keine hardwareseitigen Vorkehrungen getroffen wurden, um dies zu verhindern und eine Hardwarerevision weder im Rahmen der Abschlussarbeit noch durch den betreuenden Professor gewünscht war, habe ich eine softwareseitige Lösung implementiert.

Was folgt, ist eine vereinfachte Erklärung.

Der Dezibot in seiner vierten Iteration

Der Dezibot in seiner vierten Iteration

Die Lösung besteht aus drei Teilen:

  1. Analyse des Stromverbrauchs und Modellierung

    Um einen Überblick über die Ausgangssituation zu erlangen, habe ich einen Messaufbau hergestellt, an dem ich mittels eines Messwiderstands und eines Oszilloskops den Stromfluss durch die einzelnen Komponenten mit einer hohen zeitlichen Auflösung genau messen konnte. Dies erlaubte mir, Lastspitzen und deren Ursachen zu ermitteln, sowie ein Modell des Stromverbrauchs des Roboters basierend auf seinen durch die Software gesteuerten Tätigkeiten zu erstellen.

    Beispiel: Stromfluss durch eine WS2812B RGB-LED bei einer nicht weißen Farbe (1 mV = 1 mA)

    Beispiel: Stromfluss durch eine WS2812B RGB-LED bei einer nicht weißen Farbe (1 mV = 1 mA)

  2. Modellierung und Verwaltung des Stromverbrauchs zur Laufzeit

    Um den aktuellen Status des Roboters während der Laufzeit zu verfolgen, wurde eine Klasse namens PowerManager entwickelt, die Werkzeuge für die allgemeine Modellierung des Energiestatus des Roboters bereitstellt, wie z. B. den Ladezustand der Batterie und den Status der Stromversorgung.

    Darüber hinaus umhüllt der PowerManager eine zweite Klasse, den PowerScheduler, der die oben genannten Messungen nutzt, um alle stromverbrauchenden Komponenten des Roboters, wie Motoren, LEDs und Sensoren, sowie deren aktuellen Status zu verfolgen. Auf dieser Grundlage kann er den aktuellen Stromverbrauch des Roboters ohne tatsächliche Messvorrichtungen schätzen.

    Beispiel des Stromflusses, wie durch den PowerScheduler modelliert

    Beispiel des Stromflusses, wie durch den PowerScheduler modelliert

  3. Eingriff in das Nutzerprogramm und Informationen zur Laufzeit

    Der in den ersten beiden Schritten gewonnene Überblick wird dann verwendet, um das Laufzeitverhalten zu modifizieren. Ein klassisches Energiemanagement ist in diesem Zusammenhang nicht anwendbar, da das tatsächlich auf dem Roboter ausgeführte Programm vom Benutzer über die Arduino-IDE geschrieben wird.

    Um dies zu umgehen, wurde die Dezibot-Bibliothek, die vorgesehene Abstraktionsschicht für Benutzer dieses Roboters, so modifiziert, dass sie den Stromverbrauch kooperativ mit dem PowerScheduler koordiniert. Falls nicht genügend Strombudget übrig ist, um die beabsichtigte Aktion sicher auszuführen, wird der Benutzer über die serielle Ausgabe (Standard-UART) des ESP32 informiert und die Aktion nicht ausgeführt. Bei typischer Verwendung bedeutet dies, dass informative Meldungen im seriellen Monitor der Arduino-IDE angezeigt werden, anstatt dass der Roboter unerwartetes und schwer nachvollziehbares Verhalten (z. B. Resets oder Abstürze) zeigt, was für den vorgesehenen Anwendungsfall nachteilig wäre.

    Beispiel für eine solche Ausgabe:

    9:21:21.767 -> [ 15441][W][PowerScheduler.cpp:167] waitForCurrentAllowance():
[Power] Task 0x3fcec210 timed out waiting for 12.000000 mA of power;currently
allocated: 155.925003 mA;total available (norm/max): 120.000000/240.000000 mA

9:21:21.798 -> [ 15460][W][MultiColorLight.cpp:41] setLed(): [MultiColorLight]
Power to set LED RGB TOP RIGHT to color 0x0096002B not granted in time. Skipping.

DMX-Board (2024) Link zu Überschrift

Im Rahmen des Studienmoduls “Mikrocontroller-Anwendungen” habe ich in Zusammenarbeit mit meinem Kommilitonen Tom Wahl dieses Board und die dazugehörige Software entwickelt. Technische Grundlage ist ein ESP32-Mikrocontroller von Espressif.

Ursprüngliches Ziel im Rahmen der Prüfungsleistung war es, eine einfache Aufnahme und Wiedergabe von Lichtprogrammen, also auf dem Eingang eingehenden Daten inklusive ihres Timings zu ermöglichen.

Nach Abschluss des Moduls wurde die Hardware dann auf Anfrage des Professors noch um GPIO-Klemmen erweitert. Ziel war es, die Platine als Anschauungs- und Versuchsobjekt in Lehrveranstaltungen nutzen zu können.

Mein Fokus bei diesem Projekt lag in der Software: Die als Prüfungsleistung eingereichte Software wurde direkt auf Grundlage des ESP-IDF entwickelt, ohne Verwendung des Arduino-Frameworks. Die Ansteuerung des DMX-Busses und der Bedienelemente (OLED-Display, Encoder) erfolgen über getrennte FreeRTOS-Tasks. So kann eine Priorisierung der Bedienung des DMX-Busses sichergestellt werden.

Zusätzlich erfolgt die Ansteuerung des DMX-Busses per DMA-Controller. Dies bietet sich an, da der DMX-Bus üblicherweise von einem zentralen Knoten (dessen Rolle wir hier übernehmen), dem Controller, bespielt wird. Eine DMX-Übertragung mit Daten für alle 512 Kanäle eines DMX-Universiums benötigt ca. 22 ms. Geschieht dies nun mit der üblichen Framerate von 40 FPS, stellt man fest, dass der DMX-Bus fast durchgängig mit Daten bespielt wird. Da allerdings alle Daten bereits zu Beginn der Übertragung feststehen, wäre es ineffizient, diese unter Verwendung von CPU-Zeit durchzuführen.

Unter Verwendung von DMA kann der Mikrocontroller problemlos den DMX-Bus sowie alle andere vorhandene Peripherie bedienen, wie im Screenshot des Logic Analyzers zu sehen ist.

Versuchsaufbau der Schaltung auf Breadboard. Der Arduino Uno im oberen Teil diente vorübergehend als Logic Analyzer

Versuchsaufbau der Schaltung auf Breadboard. Der Arduino Uno im oberen Teil diente vorübergehend als Logic Analyzer

Erste zum Test geschriebene Software zur Ansteuerung eines RGBW-Strahlers. M steht hierbei für Mode, S ist bei RGB-Ansteuerung (Mode 0) nicht relevanter Zusatzparameter.

Erste zum Test geschriebene Software zur Ansteuerung eines RGBW-Strahlers. M steht hierbei für Mode, S ist bei RGB-Ansteuerung (Mode 0) nicht relevanter Zusatzparameter.

Parallele Ansteuerung der verschiedenen Datenbusse. Oben: DMX

Parallele Ansteuerung der verschiedenen Datenbusse. Oben: DMX

Schaltung als einfache CNC-gefräste Platine

Schaltung als einfache CNC-gefräste Platine

Gefertigte Platinen

Gefertigte Platinen

Board nach einem Jahr Einsatz in der Lehre an der HTWK Leipzig

Board nach einem Jahr Einsatz in der Lehre an der HTWK Leipzig

KaraoQueue (2019) Link zu Überschrift

Ursprünglich kurz vor der COVID-19-Pandemie zur Vereinfachung der Veranstaltungen entwickelt, und dann im späteren Verlauf dieser als Teil von Maßnahmen eingeführt, die es uns ermöglichen sollten, Karaoke-Abende wieder zu durchzuführen und gleichzeitig den Kontakt zwischen Menschen zu minimieren. Das Tool wird weiterhin vom Studentenklub StuK Leipzig verwendet, für den ich es geschrieben habe, während ich dort aktiv involviert war. Es erhält immer noch Fehlerkorrekturen von mir sowie gelegentliche Ergänzungen.

Die Gäste können den Liederkatalog durchstöbern (mit Vorschlägen für Lieder, die bei den vorherigen Veranstaltungen häufig gesungen wurden), die Metadaten der Lieder einsehen und sich für ihren Auftritt am Mikro eintragen. Der Moderator des Abends kann die Warteschlange einsehen und Einträge entweder annehmen oder ablehnen. Wenn ein Eintrag akzeptiert wird, wird er (anonym) zu einer Aufzeichnung der gespielten Songs der Veranstaltung sowie zu den Statistiken hinzugefügt, aus denen sich die Vorschläge ableiten.

Das Projekt ist in Python geschrieben und nutzt das Flask-Framework. Die Architektur ist als ältestes meiner überlebenden Projekte sehr simpel; zum Beispiel besteht das Frontend komplett aus handgeschriebenen Jinja-Templates, wobei alles (einschließlich handgeschriebenem JavaScript) inline enthalten ist. Als UI-Framework wird Bootstrap per statischer CSS/JS-Einbindung genutzt.

Auf der Backend-Seite wird eine MariaDB für die Datenspeicherung verwendet, und es können derzeit Katalog-CSV-Dateien im Format von Recisios KaraFun eingelesen werden. Wiedergabestatistiken können exportiert und importiert werden, funktionieren aber nur mit dem entsprechenden Katalog.

Screenshot der Hauptseite

Screenshot der Hauptseite

Ansicht der Metadaten eines Songs

Ansicht der Metadaten eines Songs

Suchansicht mit Vorschlägen

Suchansicht mit Vorschlägen

Liste der gespielten Songs des aktuellen Events

Liste der gespielten Songs des aktuellen Events

Quellcode auf GitHub Von mir für den StuK Leipzig betriebene Instanz