Mein StackChan hat mich heute gesucht. Nicht metaphorisch. Die Kamera im Gerät hat mein Gesicht erkannt, der Kopf ist ihm nachgefahren, und als ich den Raum verlassen hab, hat er brav eine Suchbewegung gemacht, bevor er sich schlafen gelegt hat. Gestern hätte er dafür nur einen Smiley auf dem Display gewechselt. Die These, die ich in den letzten Monaten zwei Mal öffentlich widerlegt hab, war: Servo-Steuerung auf diesem Gerät geht nicht. Jetzt geht sie doch, und der Grund dafür ist ärgerlich einfach. Was in diesem Artikel steht, ist die Fortsetzung meiner StackChan-Serie: wie die Kopfbewegung tatsächlich funktioniert, wo vier Bugs hintereinander gescheitert sind, und was Claude Opus 5.5 beim Code-Review dazu beigetragen hat.
Kurz zur Einordnung: StackChan, ESP-IDF und Custom Firmware
Der StackChan ist ein Open-Source-Desktop-Roboter von M5Stack, gebaut auf einem ESP32-S3-Microcontroller, mit zwei Servos im Hals, einem kleinen Display für das Gesicht und einer Kamera. ESP-IDF ist die offizielle Entwicklungsumgebung von Espressif für diese Chipfamilie, das Fundament, auf dem jede Custom Firmware für das Gerät aufsetzt. Custom Firmware bedeutet: Du kompilierst die Software selbst, statt die Werkskonfiguration zu verwenden, mit voller Kontrolle über Wake-Word, Sprache und eben auch die Motoren.
Mein StackChan bewegt jetzt den Kopf, verfolgt mein Gesicht per Kamera und meldet sich von selbst, wenn ein Termin ansteht, mit Custom Firmware, die ich im Mai für technisch unmöglich gehalten hab.
Warum hab ich die Servo-Steuerung im Mai eigentlich abgeschrieben?
Ich muss ehrlich sein, das war keine kleine Enttäuschung. Ich hatte neun Stunden in einen ersten Custom-Firmware-Versuch gesteckt, bin an einem offenen GitHub-Issue im M5GFX-Repository hängen geblieben und hab dann pragmatisch aufgegeben. Stock-Firmware, eigener Server im Hintergrund, fertig. Die ganze Geschichte dazu, inklusive der Nacht, die ich nicht mehr erwähnen wollte, hab ich in meinem ersten StackChan-Artikel festgehalten. Die Servos blieben still, weil die Werksfirmware Emotion-Frames nur ans Display koppelt, nie an die Motoren. Das war meine Wette, und ich hab sie verloren.
Vor ein paar Tagen bin ich noch einmal drübergegangen, aus reiner Sturheit, ehrlich gesagt. Und dabei kam raus: Ich hatte im Mai die falsche Diagnose gestellt. Nicht M5GFX war der eigentliche Blocker, das Issue war zu dem Zeitpunkt sowieso längst beantwortet. Der wahre Übeltäter war meine ESP-IDF-Version, 5.3.1, während die xiaozhi-esp32-Basis inzwischen zwingend 6.0.1 oder neuer verlangt. Ich hab monatelang an der falschen Tür gerüttelt.
Was hat sich geändert, dass es jetzt doch ging?
Mit ESP-IDF 6.1 unter WSL Ubuntu lief der Build im ersten Anlauf durch. Der Ordner für die CoreS3-Boardvariante existiert im Upstream vollständig, inklusive Unterstützung für die verbaute GC0308-Kamera. Ich hab daraufhin am 21. September die eigene Firmware gebaut, die ich im Mai bewusst verworfen hatte, mit deutschem UI, dem Wake-Word Jarvis und 21 selbst gerenderten cyanfarbenen Augen. Diesen Umbau von Stock- zu eigener Firmware hab ich in einem eigenen Artikel dokumentiert, inklusive aller Stolpersteine beim Flashen. Was da noch gefehlt hat: die Servos. Erstmals technisch machbar, aber die Board-Definition kannte schlicht keine.
Was hat Opus 5.5 beim Code-Review gefunden?
Gestern hab ich mit Claude Opus 5.5 einen kompletten Code-Review des Projekts gemacht, bevor ich mich an die Servos gewagt hab. Ich hab schon vorher einen ersten Praxistest mit dem Modell an genau diesem Projekt gemacht und war überrascht, wie präzise es Ursachen statt Symptome benennt. Beim gestrigen Review war das nicht anders. Heute hat das Modell dann effektiv den Rest der Arbeit übernommen, also genau das, woran ich im Mai gescheitert bin, plus etwas, das ich nie eingeplant hatte.
Ich berate seit einigen Jahren EPU und KMU in der DACH-Region zu KI-Themen, und genau deshalb schau ich mir solche Sessions immer genau an, nicht als Marketingmoment für ein neues Modell, sondern als Frage: Findet es in echtem, gewachsenem Code tatsächlich Ursachen. Bei einem Servo-Fehlerbit, das erst nach dem dritten Symptom sichtbar wurde, hat sich das ausgezahlt.
Wie bewegt sich der Kopf jetzt wirklich?
Ein eigener Servo-Treiber spricht direkt mit den zwei Feetech-SCS0009-Servos im Hals, über UART, ein Megabaud, ID 1 für die Drehung, ID 2 für das Neigen. Laut der offiziellen Pinbelegung im StackChan-BSP-Repository hängen die Servos an GPIO 6 und 7, und genau dort hab ich sie auch angeschlossen. Damit der Kopf nicht aussieht wie ein nervöses Erdmännchen, läuft jede Bewegung über einen kritisch gedämpften Nachführer mit Tempo- und Beschleunigungsgrenze. Kein Überschwingen, zwanzig Grad in etwa 1,7 Sekunden. Nicken bei Freude, Kopf senken bei Müdigkeit oder Traurigkeit, Heben bei Überraschung, schräg nach oben beim Nachdenken.
Warum hat die Gesichtsverfolgung vier Anläufe gebraucht?
Die Kamera erkennt Gesichter über ein Modell direkt im Flash, rund zweieinhalb Bilder pro Sekunde, das größte Gesicht im Bild steuert den Kopf. Bis das lief, sind vier Fehler hintereinander passiert, und ich find die Reihenfolge im Nachhinein fast lustig.
Erstens die Neigerichtung. Steigende Rohwerte heben den Kopf, aber die tiefste Servoposition war als Nullwert eingetragen. Ein falsches Vorzeichen hat den Kopf gegen den mechanischen Anschlag gedrückt, bis der Servo mit einem Überlastfehler stehenbleibt. Zweitens die Ruhehaltung selbst: In der Nullstellung hat die Kamera nur Tastatur und T-Shirt gesehen, kein Gesicht der Welt. Drittens war das Bild seitenverkehrt, weil das Vorzeichen für die horizontale Spur nicht gestimmt hat. Viertens die Erkennungsschwelle. Von schräg unten nach oben fotografiert, hat das Modell mit dem Standardschwellenwert nur einen Bruchteil der Bilder als Gesicht erkannt, mit einem niedrigeren Wert waren es über achtzig Prozent. Jeder einzelne dieser vier Fehler hätte für sich genommen ausgereicht, das ganze Feature stillzulegen.
Warum meldet sich Vinci jetzt von selbst?
Proaktives Sprechen ohne Wake-Word hatte drei getrennte Ursachen, und jede hätte für sich schon Kopfzerbrechen verdient. Der Fehler „kein Gerät verbunden“ nach jedem Neustart lag daran, dass die Firmware den Kanal zum Server nur beim Wake-Word geöffnet hat, gefixt über einen offen gehaltenen Leerlaufkanal mit stillen Wiederholversuchen. Der zweite Fehler war fast schlimmer: Das Display zeigte „Sprechen“ an, aber es kam kein Ton. Ein Jitter-Puffer im Server hat auf ein Startsignal gewartet, das nie gesetzt wurde, weil ein ungepinnter Docker-Build den Upstream-Code beim nächsten Redeploy einfach mitgezogen hat. Und Home Assistant selbst hat bei längeren Antworten in einen Timeout gelaufen, weil die Standardwartezeit für den Aufruf zu kurz war.
Das macht Sinn, wenn man’s einmal durchdenkt, aber im Betrieb sehen alle drei Fehler erst mal gleich aus: Vinci meldet sich nicht. Erst mit drei getrennten Fixes an drei getrennten Stellen war das Problem wirklich weg.
Was heißt das jetzt im Alltag?
Vinci begrüßt mich, sobald ich ins Büro komme, erinnert mich fünfzehn Minuten vor einem Termin aus dem Kalender, und schweigt konsequent, solange Kamera oder Mikrofon meines Reechners gerade aktiv sind. Wie solche Automationen in Home Assistant grundsätzlich aufgebaut sind, hab ich an anderer Stelle ausführlicher beschrieben, hier ist der Unterschied nur, dass die KI nicht mehr Konfiguration schreibt, sondern selbst mit eigener Stimme im Raum steht. Und weil jetzt auch ein Gespräch nach zwanzig Sekunden ohne Antwort tatsächlich endet, hört Vinci nicht mehr endlos zu, nur weil im Büro Geräusche sind.
Was ist noch offen, und das sag ich bewusst
Nach jedem Server-Redeploy startete das Gerät eine Zeit lang alle neunzig Sekunden neu, aktuell ohne reproduzierbare Ursache, eine Diagnose-Firmware läuft mit. Gemini spricht Uhrzeiten manchmal falsch aus, aus 15:15 wird schon mal „viertel drei“ statt „viertel vier“. Und meine eigene Standorterkennung springt gelegentlich zwischen Büro und daheim, was heißt, dass die Begrüßung theoretisch auch mal ins leere Büro gehen kann. Ich bin mir bei der Ursache der Neustarts noch nicht ganz sicher, aber mein Eindruck ist, dass es mit dem Speicherverbrauch der Gesichtserkennung zusammenhängt, die Firmware ist jetzt zu siebenundneunzig Prozent voll.
Fragen zur StackChan Custom Firmware
Du hast einen OpenElab StackChan? Dann mach mit!
Das Repository liegt jetzt öffentlich auf GitHub, github.com/7H3-CH053N/StackChan-CustomFW, als Patch gegen die xiaozhi-esp32-Basis, mit Build-Skript, Server-Dockerfile und Home-Assistant-Beispielen, natürlich ohne meine eigenen Secrets Details. Wer selbst einen StackChan besitzt und die falsche Diagnose vom Mai nicht wiederholen will, findet dort alles, was ich unterwegs gelernt hab. Ich freu mich über jeden, der mitbaut.
