Gamepad Bridge

Es ist im Urlaub entstanden, aus einem privaten Ärgernis heraus, für meine Kinder und ein Spielzeug in unserem Wohnzimmer. Kein Auftraggeber, kein Budget, keine Freigabe, die ich einholen musste — und entsprechend keine Zeile davon, die ich als Referenz für bezahlte Arbeit ausgeben würde.

Es steht trotzdem hier, weil an einem Projekt ohne Auftraggeber etwas sichtbar wird, das ein Kundenprojekt nie zeigt: wie jemand vorgeht, wenn er von der Sache noch nichts versteht. Ich hatte vor diesem Projekt nie Firmware geschrieben. Was Sie hier lesen, ist deshalb weniger eine Leistungsschau als ein offengelegter Arbeitsweg — mitsamt der Abende, an denen er in die falsche Richtung führte.

Firmware, Smoketest und die Protokollnotizen liegen vollständig offen auf GitHub, unter MIT-Lizenz. Wer dasselbe Modell besitzt, muss das Messen nicht wiederholen.

Das Fahrzeug ist ein LEGO®-Technic™-Modell mit einem Move Hub — einem Baustein, der Motoren, Lenkung, Licht und Akku in sich vereint und ausschließlich per Bluetooth angesprochen wird. Vorgesehen ist dafür genau ein Bedienweg: die hauseigene Handy-App.

Für eine Vorführung reicht die. Zum Fahren taugt sie nicht, und der Grund ist keine Geschmacksfrage. Ein Trigger hat einen Weg und eine Feder. Man spürt, wie weit man gedrückt hat, ohne hinzusehen, und die Hand korrigiert, bevor der Kopf es merkt. Eine Fläche aus Glas hat davon nichts: kein Weg, kein Widerstand, keine Rückmeldung. Man lenkt, indem man den Daumen über etwas schiebt, das nicht zurückdrückt — und schaut dabei aufs Telefon statt aufs Auto.

Dazu kam der Grund, der den Ausschlag gab: die App braucht ein Smartphone. Meine Kinder haben keins. Das Auto fuhr also nur, wenn ein Erwachsener danebenstand und das Telefon hielt. Ein Controller dagegen liegt bei uns ohnehin herum, und wie man ihn hält, weiß hier jeder.

Übrig blieb ein kleiner Mikrocontroller, der zwei Bluetooth-Verbindungen gleichzeitig hält — eine zum Controller, eine zum Fahrzeug — und zwischen beiden übersetzt. Er muss nirgends eingebaut werden; beide Beine sind Funk. Er liegt einfach dazwischen.

Ich bin Maschinenbauer. Vor diesem Projekt hatte ich nie Firmware geschrieben, nie einen Bluetooth-Stack angefasst und kein einziges Byte des LEGO Wireless Protocol gelesen. Der Code ist mit Unterstützung eines KI-Assistenten entstanden, und das ist keine Fußnote, sondern die Methode: ich beschreibe, was passieren muss und warum; der Assistent schreibt den Code und erklärt den Mechanismus; ich prüfe beides am realen Auto.

Diese dritte Stufe ist die entscheidende. Ein Sprachmodell klingt genauso überzeugt, wenn es irrt, wie wenn es recht hat — es hat keinen Zugriff auf das Fahrzeug und kann deshalb nicht wissen, ob es stimmt. Jede Aussage über das Protokoll in diesem Projekt ist am Auto gemessen, nicht hergeleitet; wo etwas nicht messbar war, steht das ausdrücklich dabei statt einer Vermutung. Fünf der Messungen widersprechen der vorhandenen Dokumentation, drei davon stehen weiter unten.

So verschiebt sich die Arbeit, aber sie verschwindet nicht. Was ein Sprachmodell an Wochen erspart, gewinnt man nur, wenn man die gesparte Zeit ins Prüfen steckt — sonst hat man in derselben Woche viermal so viel Code, der nicht funktioniert, und keine Idee, warum.

Und die ehrliche Kehrseite: Das ist Hobby-Code. Er läuft auf meinem Aufbau, jeden Tag, und meine Kinder fahren damit. Ich behaupte nicht, dass er fehlerfrei ist — im Repository steht derselbe Satz, in der ersten Person und vor allem anderen.

Der Hub hat einen eigenen Geschwindigkeitsregler. Alles, was die Brücke zusätzlich glättet, regelt oder umrechnet, macht Arbeit doppelt — und zwei Regler in Reihe sind kein doppelt guter Regler, sondern ein schlechter. Vier Funktionen waren gebaut, gemessen und sind wieder geflogen.

Das Ziel war die Bedienung. Was dabei nebenbei auffiel, wurde am Ende der Teil, der am meisten Spaß gemacht hat.

Der Hub hat sechs Lichtausgänge, ringförmig um seine Mitte angeordnet. Das Modell nutzt vier davon — zu den anderen beiden führt kein Lichtleiter, am Auto ist von ihnen nichts zu sehen. Die App kennt sie nicht, und dass sich die sechs überhaupt einzeln ansteuern lassen, stand in keiner Unterlage, die ich gefunden habe.

Sie lassen sich einzeln ansteuern. Zwei Bytes genügen: eine Bitmaske, welche Lampe gemeint ist, und eine Helligkeit. Zwei Fallen stecken darin — die Maske schaltet nur ein, was gesetzt ist, und nichts aus, und der Hub setzt die Lampen von sich aus nie zurück. Wer das übersieht, hat nach zehn Minuten ein Auto, das überall gleichzeitig leuchtet.

Damit war plötzlich eine Menge möglich, die nie auf dem Zettel stand:

Bleiben die zwei Ausgänge, die am Modell nirgendwohin führen. In der Firmware sind sie längst belegt — mit seitlichen Blinkern, die dieses Modell ab Werk nie hatte. Was fehlt, ist Bauarbeit: flexible Lichtleiter von den beiden Ausgängen an die Flanken. Die Teile dafür sind bestellt. Aus vier Lichtpunkten am Modell werden dann sechs.

Das war der schönste Teil des ganzen Projekts — mehr als das Bauen, mehr als das Fahren. Nicht weil es schwer gewesen wäre, sondern weil niemand danach gefragt hatte. Solche Sachen findet man nicht, indem man eine Anforderungsliste abarbeitet. Man findet sie, weil man ohnehin gerade in einem System nachsieht, das man verstehen muss.

Bevor überhaupt etwas fahren konnte, musste das Auto fahrbereit sein — und das war es nicht. Es lag in Einzelteilen in seiner Schachtel, so wie Modelle bei Kindern eben irgendwann zurückkommen. Ich habe es also noch einmal gebaut, mit der Anleitung meines Sohnes: ein paar Stunden, verteilt auf zwei Urlaubstage.

Wer schon einmal LEGO gebaut hat, kennt den Ablauf: Schritt lesen, Form merken, wühlen. Und dabei passiert etwas, das mir vorher nie aufgefallen war. Man wühlt durch alle Teile — und dabei hundertmal hintereinander durch genau das Teil, das man später erst brauchen wird. Es liegt direkt vor einem, es ist scharf, das Auge sieht es. Wahrgenommen wird es nicht. Es verschwimmt mit dem Hintergrund.

Dann kam der Schritt mit dem Teil, das ich noch nie gesehen hatte — und das ich an diesem Tag schon hundertmal zwischen den Fingern gehabt hatte, ohne es zu wissen. Eine graue Hülse: an beiden Enden ein Bund, an einem Ende ein Schlitz. So eigenartig, dass sie mir hätte auffallen müssen.

Ich habe zwei Sekunden gebraucht, um sie zu finden. Zwei Sekunden für ein Teil, an dem ich stundenlang vorbeigegriffen hatte.

Die Hülse liegt auch auf dem Foto weiter oben. Sie haben es vorhin schon angesehen.

Der Gegenstand war ein Spielzeug. Alles drumherum war gewöhnlicher Arbeitsalltag: eine undokumentierte Schnittstelle, ein System, das man nicht verändern darf, ein Ausfall, der nach etwas anderem aussah, als er war — und als Terminplan genau die Abende, die übrig blieben.

Übertragbar ist nicht das Ergebnis, sondern das Vorgehen. Messen statt annehmen. Den Versuch bauen, der die Erklärungen trennt, statt Argumente zu sammeln. Wegnehmen, was doppelte Arbeit macht. Die Beobachtbarkeit herstellen, bevor man sie braucht. Und am Ende in die Hand nehmen, was man gebaut hat, weil manche Entscheidungen nur dort fallen.

Die Domäne war neu für mich, das Vorgehen nicht. Bei Ihnen ist der Gegenstand ein anderer — Mechanik, Hardware, Software oder alle drei zusammen. Die Schritte wären dieselben.