Sieben Zwerge, ein Assistent: Wie verteilte ESP32-Systeme die persönliche KI neu definieren

Autor: DerSchneider

Einleitung

Es klingt nach dem Beginn eines Märchens: Sieben Mikrocontroller, ein Mikrofon, ein Lautsprecher, ein Drehgeber und ein kleines Display – zusammengesteckt zu einem Sprachassistenten, der nicht nur auf „Hey Zwergi“ hört, sondern auch die Stimmung seines Gegenübers erkennt. Was auf den ersten Blick wie ein Bastelprojekt für Elektronik-Enthusiasten wirkt, berührt tiefgreifende Fragen der modernen Digitalkultur: Wie viel Intelligenz braucht ein Gerät wirklich? Wo liegt die Grenze zwischen hilfreicher Personalisierung und manipulativer Emotionerkennung? Und ist ein dezentrales System aus sieben günstigen Mikrocontrollern nicht vielleicht die nachhaltigere Alternative zu den monolithischen Cloud-Assistenten der großen Tech-Konzerne?

Dieser Artikel beleuchtet ein konkretes Projekt – den Bau eines verteilten, sprachgesteuerten KI-Assistenten auf Basis von sieben ESP32-Boards – und zieht daraus weiterführende Schlüsse für die Entwicklungsgeschichte der Mensch-Maschine-Interaktion, die technischen Herausforderungen von TinyML und die ethischen Implikationen emotionserkennender Algorithmen.

Hauptteil

1. Historische Entwicklung: Von der Zentralmaschine zum Schwarm

Die ersten kommerziellen Sprachassistenten – Amazons Alexa (2014), Google Assistant (2016) – waren Kind ihrer Zeit: Sie verlagerten die gesamte Sprachverarbeitung in die Cloud. Das Endgerät diente nur als akustisches Ein-/Ausgabetor. Diese Architektur brachte enorme Rechenleistung, aber auch Abhängigkeiten von Internetverbindungen, Latenzen und zentralen Datenkraken mit sich.

Mit dem Aufkommen von Mikrocontrollern wie dem ESP32 (Espressif Systems, 2016), der neben WLAN und Bluetooth auch ausreichend Rechenleistung für einfache neuronale Netze bietet, entstand die Möglichkeit, Edge AI – also die Verarbeitung direkt auf dem Gerät – zu realisieren. TensorFlow Lite Micro, erstmals 2019 von Google vorgestellt, ermöglicht es, Modelle mit wenigen hundert Kilobyte auf Mikrocontrollern laufen zu lassen. Gleichzeitig eröffnete die extreme Kostenreduktion (ein ESP32 kostet unter 5 €) den Weg zu verteilten Systemen: Mehrere spezialisierte Einheiten arbeiten zusammen, statt alles in einem leistungsstarken, teuren Chip zu bündeln.

Das hier vorgestellte System mit sieben Boards führt diesen Gedanken radikal zu Ende. Es erinnert an die frühen Mehrrechner-Systeme der 1970er Jahre, allerdings mit einem entscheidenden Unterschied: Heute kommunizieren die Einheiten über einfache Zweidraht-Busse (I²C) und können individuell trainiert werden.

2. Architektur des 7‑Board-Systems – Arbeitsteilung nach dem Schwarmprinzip

Jedes der sieben ESP32-Boards übernimmt eine klar abgegrenzte Aufgabe. Dies reduziert die Komplexität des Einzelcodes, erhöht die Ausfallsicherheit und ermöglicht einen modularen Aufbau. Die folgende Tabelle fasst die Verteilung zusammen:

Vorteile dieser Aufteilung:

• Fehlertoleranz: Fällt Board 3 aus, können zumindest Offline‑Befehle weiterverarbeitet werden.
• Skalierbarkeit: Weitere Sensoren (z. B. Temperatur, Luftfeuchte) lassen sich als zusätzliche Boards anbinden.
• Wartbarkeit: Ein Software‑Update für die Emotionserkennung berührt nicht den Wake‑Word‑Code.

Herausforderung: Die Kommunikation über den gemeinsamen I²C‑Bus (Standard: 100 kHz, maximal 3,4 MHz) kann bei gleichzeitigen Anfragen zum Flaschenhals werden. Im Projekt werden daher kurze Steuerbefehle (wenige Bytes) über I²C gesendet, während Audio‑Rohdaten (z. B. für die Emotionserkennung) besser über einen separaten SPI‑Bus oder per UART übertragen werden. Eine echte Echtzeit‑Sprachverarbeitung über reinen I²C wäre nicht möglich.

3. Funktion 1: Wake‑Word‑Erkennung mit TensorFlow Lite Micro

Das „Aufwecken“ des Assistenten ohne ständige Cloud‑Verbindung ist ein klassischer Anwendungsfall für lokal laufende neuronale Netze auf Mikrocontrollern. Das Trainieren eines eigenen Wake‑Worts wie „Hey Zwergi“ erfolgt typischerweise mit Edge Impulse oder dem TensorFlow Wake‑Word Dataset (eine Sammlung von zwölf Schlüsselwörtern). Das resultierende Modell ist ein konvolutionales neuronales Netz (CNN) mit wenigen Layern, das auf einem ESP32 in weniger als 50 ms eine Inferenz durchführt.

Technische Kenndaten:

• Modellgröße: ca. 30 kB (quantisiert, int8)
• RAM‑Bedarf: ~10 kB
• Erkennungsrate: >90 % bei ruhiger Umgebung, sinkt auf ~70 % bei hohem Störgeräusch

Die Schwelle für eine Auslösung (klassisch 0,8) lässt sich über das Drehencoder‑Menü (Board 6) dynamisch anpassen – ein Feature, das bei kommerziellen Produkten oft fehlt. Kritisch zu sehen ist die unvermeidbare False‑Positive‑Rate: Ungefähr alle 20 Minuten löst ein Hintergrundgeräusch (z. B. ein Husten) fälschlich das Wake‑Word aus. Im Projekt wird deshalb eine zusätzliche „Abklingzeit“ von drei Sekunden eingeführt – ein pragmatischer Kompromiss.

4. Funktion 2: Multimodale Interaktion – Der Wert haptischer Rückmeldung

Warum ein Drehencoder und Taster, wo man doch einfach sprechen kann? Die Antwort liegt in der redundanten Bedienbarkeit. In lauten Umgebungen (Küche, Werkstatt) oder bei akuten Sprachproblemen (Heiserkeit, soziale Hemmung) bieten physische Eingaben eine robuste Alternative. Zudem erlaubt ein Encoder eine präzise, stufenlose Regelung (z. B. Lautstärke, Kontext-Menüs) – etwas, das Sprachbefehle nur mit mehreren aufeinanderfolgenden Kommandos erreichen.

Die Implementierung auf Board 6 nutzt eine ESP32Encoder‑Bibliothek, die die beiden Phasensignale des EC11‑Drehencoders auswertet. Das OLED‑Display zeigt dabei nicht nur den Status („Wake‑Word erkannt“, „Emotion = fröhlich“), sondern auch ein einfaches Einstellungsmenü:

text

> Lautstärke: 70%
   Empfindlichkeit: 0,8
   Prompt ändern
   Chatverlauf löschen

Diese asynchrone Steuerung entkoppelt die Interaktion von der Sprach‑KI – ein großer Gewinn an Benutzerfreundlichkeit.

5. Funktion 3: Emotionserkennung in der Sprache – Segen oder Übergriff?

Die dritte Erweiterung ist die ambitionierteste und zugleich fragwürdigste: Das System analysiert prosodische Merkmale der Stimme (Tonhöhe, Sprechgeschwindigkeit, Energieverteilung) und ordnet sie einer von vier Grundemotionen zu: neutral, fröhlich, traurig, wütend. Technisch wird dies typischerweise mit MFCC‑Features (Mel Frequency Cepstral Coefficients) und einem kleinen Random‑Forest‑ oder neuronalen Netz realisiert. Die Genauigkeit liegt in kontrollierten Tests (z. B. mit dem Berliner EMODB-Datensatz, 2007) bei etwa 75 %, in freier Wildbahn oft unter 60 %.

Damit verbundene Probleme:

• Kulturelle Abhängigkeit: Tonlage und Ausdrucksweise variieren stark zwischen Sprachen und sozialen Gruppen. Ein auf deutsche Standardsprache trainiertes Modell versagt bei Dialekten oder Menschen mit Sprechstörungen.
• Datenschutz: Emotionen gelten als besonders schützenswerte biometrische Daten (Art. 9 DSGVO). Das Speichern von Emotionslabels auf Board 7 (zusammen mit der Chat‑Historie) könnte rechtswidrig sein, wenn keine explizite Einwilligung vorliegt.
• Selbsterfüllende Prophezeiung: Ein System, das „Wut“ erkennt, könnte defensiv oder unterwürfig antworten – und so die emotionale Lage des Nutzers weiter verschlechtern.

Die Entwickler des hier beschriebenen Projekts sehen die Emotionserkennung daher weniger als diagnostisches Werkzeug, sondern als experimentelle Spielwiese, um über die ethischen Grenzen von KI zu reflektieren. Ein differenzierter Ansatz wäre, die erkannte Emotion lediglich als nichtspeicherbaren Hinweis für die Prompt‑Generierung zu nutzen, ohne sie jemals aufzuzeichnen.

6. Kommunikation über I²C – Der Bus als zentraler Nerv

Die sieben Boards tauschen sich über einen gemeinsamen I²C‑Bus aus. Jedes Board hat eine feste Adresse (0x10 … 0x16). Das Protokoll ist minimalistisch: Ein Byte Befehlscode, gefolgt von bis zu 32 Datenbytes. Diese Schlichtheit macht den Bus robust, aber auch langsam. Für den hier vorgesehenen Datenaustausch – Steuerbefehle, kurze Textstrings, Emotions‑Labels – ist das völlig ausreichend. Die Übertragung eines zwanzigstelligen Satzes (20 Byte) dauert bei 100 kHz etwa 2 ms – vernachlässigbar im Vergleich zu den 200 ms Latenz einer Cloud‑KI.

Kritische Betrachtung: Sobald man jedoch Audio‑Rohdaten (z. B. für eine direkte Wake‑Word‑Weitergabe an Board 2) über I²C schicken wollte, wäre die Bandbreite (max. 400 kBit/s im Fast‑Mode) schnell erschöpft. Aus diesem Grund bleibt die Audio‑Erfassung ausschließlich Board 1 vorbehalten; Board 2 erhält nur bereits extrahierte Merkmalsvektoren (z. B. 20 MFCCs pro Frame). Das ist ein gutes Beispiel für Signaltransformation an der Quelle – ein wichtiges Prinzip verteilter Systeme.

7. Kontroversen und ethische Abwägungen

Das Projekt wirft drei zentrale Kontroversen auf:

1. Cloud‑Abhängigkeit vs. Offline‑Fähigkeit
   Die Cloud‑Kommunikation (Board 3) ist für die Nutzung großer Sprachmodelle (wie DeepSeek-V3 oder GPT) unerlässlich. Allein die Auslagerung von Sprachdaten in fremde Rechenzentren ist datenschutzrechtlich bedenklich. Ein echter Offline‑Betrieb ist nur für triviale Antworten („Uhrzeit“, „Licht an“) mit winzigen TinyML‑Modellen möglich. Der Kompromiss: nur die finale Textanfrage – nicht die Rohaufnahme – wird in die Cloud gesendet.
2. Hardware‑Overkill?
   Sieben separate ESP32 verbrauchen mehr Energie (pro Board ~80 mA im aktiven Modus) und Platz als ein einzelner leistungsfähigerer Chip (z. B. Raspberry Pi Zero 2 W). Der Vorteil ist die didaktische Klarheit: Jede Funktion ist physisch getrennt, Studenten und Hobbyisten können einzelne Module austauschen oder verbessern, ohne das Gesamtsystem zu gefährden.
3. Emotionserkennung als manipulatives Werkzeug
   Selbst eine fehlerhafte Erkennung kann schwerwiegende Folgen haben. Ein Kind, dessen Traurigkeit nicht erkannt wird, fühlt sich möglicherweise noch unverstandener. Ein System, das auf „fröhlich“ trainiert ist, könnte unangemessen heitere Antworten auf ernste Fragen geben. Die Entwickler betonen daher: Die Emotionserkennung dient ausschließlich der Forschung und Selbstreflexion, nicht als Produktmerkmal.

Fazit und Ausblick

Die sieben ESP32‑Boards, verbunden durch einen einfachen I²C‑Draht, demonstrieren eindrucksvoll, dass leistungsfähige, personalisierte Sprachassistenten nicht nur in den Händen großer Konzerne liegen müssen. Die gezeigten Funktionen – Wake‑Word, multimodale Bedienung und Emotionserkennung – sind mit überschaubarem Aufwand realisierbar und bieten gleichzeitig reichhaltiges Material für technikethische Diskussionen.

Zukünftige Entwicklungen könnten sein:

• Verwendung von ESP‑Now (einem peering‑fähigen Protokoll) für eine latenzärmere Kommunikation zwischen den Boards.
• Integration von On‑Device‑Transkription (Whisper.cpp für ESP32 – ein heißes Forschungsfeld, derzeit noch zu rechenintensiv).
• Erweiterung um ein federated learning – jedes Board trainiert sein Wake‑Word lokal, nur die Gewichtsaktualisierungen werden gelegentlich gebündelt abgeglichen.

Das Projekt lebt von seinem Prototyp‑Charakter. Es ist nicht dafür gedacht, Alexa zu besiegen, sondern zu zeigen, wie offene Hardware, TinyML und ein bisschen Improvisationsgeist zusammenwirken können. Gerade in Zeiten zunehmender „Black‑Box“-Assistenten ist es erfrischend, die Drähte selbst zu ziehen und die Entscheidungslogik des Zwergen‑Teams nachvollziehen zu können.

Quellen

• Espressif Systems (2024). ESP32‑Series Technical Reference Manual. Online abrufbar.
• Google (2019). TensorFlow Lite Micro for Microcontrollers. Dokumentation.
• Edge Impulse (2022). Wake‑Word Spotting with Edge Impulse. Dokumentation.
• Burkhardt, F., Paeschke, A., Rolfes, M., Sendlmeier, W. & Weiss, B. (2007). A Database of German Emotional Speech. In: Proc. Interspeech, S. 1517–1520. (EMO‑DB)
• Schuller, B., Batliner, A., Bergler, C. & Messner, E. (2018). Paralinguistic Speech Processing: An Overview. IEEE Signal Processing Magazine, 35(1), 19–31.
• Verordnung (EU) 2016/679 (DSGVO), Art. 9 – Verarbeitung besonderer Kategorien personenbezogener Daten.