Proxi AI

Mein Sohn Ben hat einen Roboter. Proxi, ein Bausatz von KOSMOS, mit einem BBC micro:bit als Kopf. Man baut ihn zusammen, programmiert ihn mit bunten Blöcken im Browser, spielt das Ergebnis per USB-Kabel auf — und dann läuft er genau das Programm, das man ihm gegeben hat.

Ben wollte mehr. Er wollte mit dem Roboter reden.

Die Idee war schnell umrissen: eine Firmware, die einmal aufgespielt wird und danach über Bluetooth auf Textbefehle hört. Was diese Befehle schickt, ist ihr egal — ein Skript, ein curl, oder eben ein KI-Agent, der aus „lass ihn tanzen" eine Choreografie baut.

Was daraus wurde, ist ein Abend, der mir mehr über die Arbeit mit KI beigebracht hat als die letzten drei Fachartikel zusammen. Nicht weil es so gut lief. Sondern weil es an drei Stellen richtig danebenging — und weil jede dieser Stellen etwas darüber verrät, was KI kann und was nicht.

Erster Anlauf: eine Firmware für einen Roboter, den es nicht gibt

Den ersten Versuch hatte ich mit meiner KI-Assistentin gebaut. Das Ergebnis sah hervorragend aus. Sauber strukturierter Code, Kommentare, ein durchdachtes Befehlsprotokoll mit Geschwindigkeitsregelung, Servo-Steuerung für den Oberkörper, Touch-Sensoren. Nur: Proxi bewegte sich nicht.

Die Fehlersuche brachte etwas zutage, das ich so nicht erwartet hatte. Die Firmware war nicht fehlerhaft. Sie war für einen Roboter geschrieben, den es nicht gibt.

Kein einziger Pin stimmte. Sie schrieb Motorsignale auf Kontakte, an denen in Wahrheit der Summer und ein Infrarot-Empfänger hängen. Sie steuerte einen Servo an, den Proxi gar nicht besitzt. Sie las Touch-Sensoren aus, die es an diesem Roboter nicht gibt.

Und der Grund dafür lag im Projektordner selbst: Dort lagen Python-Dateien, die angeblich die Beispielprogramme des Herstellers enthielten — mit genau dieser Pin-Belegung. Diese Dateien waren ebenfalls von einer KI erzeugt worden. Frei erfunden, plausibel formatiert, vollständig falsch. Die zweite KI hatte sie gelesen und ihnen geglaubt.

Das ist der interessante Teil: Es war kein Denkfehler. Es war eine Kette. Eine KI erfindet etwas Plausibles, die nächste nimmt es als Tatsache. Niemand log, niemand pfuschte — und heraus kam trotzdem Software für eine Fantasie-Hardware.

Wo steht die Wahrheit?

KOSMOS dokumentiert die Pin-Belegung nirgends. Die Anleitung richtet sich an Kinder, programmiert wird ausschließlich mit den fertigen Blöcken. Es gibt kein Datenblatt, keine Schaltpläne, kein Wiki.

Was es gibt, sind die mitgelieferten .hex-Dateien der Beispielprogramme. Und darin steckt mehr, als man denkt: Der MakeCode-Editor hängt an jede kompilierte Firmware das komplette Quellprojekt an — komprimiert, aber vollständig.

Also habe ich ein kleines Werkzeug gebaut, das genau das wieder herausholt. Zwanzig Zeilen, die die Datei zerlegen, den angehängten Block entpacken und den Quelltext zurückgeben. Und plötzlich lag die Hardware-Anbindung des Herstellers offen da — inklusive der Datei, die alle Hardware-Zugriffe kapselt.

Die Wahrheit sah anders aus als die Erfindung:

Zwei Motoren, rein digital. An oder aus, keine Zwischenstufen. Es gibt keine Geschwindigkeitsregelung — gesteuert wird ausschließlich über die Dauer. Ein Befehl wie „fahre mit Tempo 300" ergibt an diesem Roboter keinen Sinn.
Infrarot mit Puls-Messung. Erst den Umgebungswert lesen, dann die Sendediode einschalten, 250 Mikrosekunden warten, erneut messen. Die Differenz ist der Messwert — so fällt das Umgebungslicht heraus.
Kein Servo, keine Touch-Sensoren. Hat der Roboter schlicht nicht.

Nebenbei stellte sich heraus, dass Proxi baugleich zu einem anderen Roboter ist und die Hersteller-Erweiterung eine eingedeutschte Fassung eines MIT-lizenzierten Projekts. Das war die Gelegenheit, die Motorsteuerung unverändert zu übernehmen statt sie nachzubauen. Fremder, erprobter Code schlägt eigenen, geratenen.

Der Fehler, der wie drei Fehler aussah

Firmware neu, Brücke neu, Protokoll neu. Der Roboter fuhr, drehte sich, zeigte Gesichter. Dann kam die Musik.

Und mit ihr ein Fehler, der sich wie ein Spuk verhielt: Der Lautsprecher krachte ohrenbetäubend, das Programm blieb hängen, und nach ein paar Sekunden riss die Bluetooth-Verbindung ab. Mal nach einer Melodie, mal nach dreien, einmal nach einem einzelnen Ton.

Ich hatte drei Erklärungen. Alle drei klangen überzeugend. Alle drei waren falsch.

Zuerst verdächtigte ich den eingebauten Melodie-Player: Der spielt in einem eigenen Nebenläufer ab, auf den man keinen Zugriff hat — greift gleichzeitig etwas anderes auf den Ton zu, kollidieren sie. Klang zwingend. Ich baute ihn aus und ersetzte ihn durch eigene Wiedergabe. Der Fehler blieb.

Dann der interne Lautsprecher des micro:bit V2. Auch plausibel. Auch falsch. Schlimmer noch: Beim Gegentest drehte ich nur die Hälfte meiner Änderung zurück und schloss aus dem Ergebnis, die ganze Änderung sei unnötig. Also entfernte ich die Zeile, die das Problem tatsächlich behob — und schickte das Ergebnis als „finale Fassung" weiter.

Erst danach hörte ich auf zu raten.

Ich baute Diagnosebefehle in die Firmware ein, die jeweils genau eine Variable isolierten: nur rechnen ohne Ton. Ein einzelner Ton. Mehrere Töne. Und ich schnitt auf der Gegenseite den Bluetooth-Verkehr mit, um zu sehen, wer die Verbindung eigentlich beendet.

Das Ergebnis war eindeutig und ernüchternd:

DIAG:NOTE:79:200   (Frequenz berechnet)  -> Krachen, hängt, Verbindung weg
TONE:784:200       (Frequenz übergeben)  -> sauberer Ton

Dieselbe Firmware, derselbe Codeweg, dieselben 784 Hertz. Der einzige Unterschied: Einmal war die Zahl das Ergebnis einer Kommazahl-Rechnung, einmal kam sie direkt aus dem Befehl.

Das war es. Eine einzige Zeile. Ich hatte die Tonhöhe mit einer Potenzfunktion berechnet — mathematisch völlig korrekt, eine Diagnoseabfrage lieferte sauber 784. Aber als Kommazahl kam der Wert in der Tonausgabe falsch an. Der Mikrocontroller machte daraus eine unsinnige Schwingungsdauer, der Lautsprecher kreischte, der Aufruf kehrte nie zurück, und weil der Chip damit den Funk nicht mehr bediente, gab die Gegenseite die Verbindung auf.

Ein Fehler. Drei Symptome. Die aussahen wie drei getrennte Probleme.

Was ich daraus mitnehme

Plausibel ist nicht wahr. Der teuerste Teil dieses Projekts war nicht das Programmieren. Es war der Umstand, dass an drei Stellen etwas völlig Überzeugendes im Weg stand: erfundene Datei-Inhalte, die aussahen wie Dokumentation, und meine eigenen Theorien, die jedes Mal Sinn ergaben.

Ein Gegentest, der die These nicht prüfen kann, ist schlimmer als kein Test. Zweimal ist mir das passiert. Einmal drehte ich nur die halbe Änderung zurück. Ein anderes Mal leuchtete ich mit einer Taschenlampe auf einen Sensor, um zu beweisen, dass er funktioniert — durch eine getönte Scheibe hindurch, die genau das verhinderte. Beide Male fühlte es sich nach Evidenz an. Beide Male war es keine.

Messen schlägt Schließen. Gelöst wurde der Fehler nicht durch die vierte Theorie, sondern durch ein Werkzeug, das immer nur eine Sache auf einmal veränderte. Das ist unspektakulär und dauert länger, als sich eine Erklärung auszudenken. Es ist aber der einzige Weg, der zuverlässig ankommt.

Und die Rückmeldung aus der echten Welt ist unersetzlich. Den blockierten Sensor habe ich nicht durch Nachdenken gefunden. Ben hat die Scheibe abgenommen und nachgesehen. Zwei Minuten, nachdem ich zwei Softwaretheorien daran verschlissen hatte.

Genau das ist übrigens meine Antwort, wenn mich Unternehmen fragen, was KI heute leisten kann. Sehr viel — dieses Projekt entstand an einem Abend, nicht in einem Monat. Aber sie erfindet mit derselben Überzeugung, mit der sie Richtiges produziert. Der Unterschied liegt nicht im Tonfall, sondern in der Überprüfung. Wer das einplant, bekommt enorme Hebel. Wer es überspringt, bekommt eine Firmware für einen Roboter, den es nicht gibt.

Und Ben?

Ben hat inzwischen seinen eigenen KI-Agenten. Er sagt ihm, was Proxi tun soll, der Agent baut die Befehle, der Roboter tanzt. Zu einer 16 Sekunden langen Melodie, mit Wackeln, Stampfen und einer großen Schlussdrehung.

Der ganze Kram ist Open Source — Firmware, Brücke, Protokoll, der Agent-Skill und das Werkzeug, das den Quelltext aus .hex-Dateien holt. Die Pin-Belegung ist dokumentiert, damit sie der Nächste nicht erneut ausgraben muss. Und die beiden Fallstricke stehen mit Messwerten dabei, statt verschwiegen zu werden.

Denn der Teil, an dem man hängenbleibt, ist der Teil, der in Dokumentationen üblicherweise fehlt.

Das Projekt auf Gitea: gitea.gaertner.onl/christian/proxi-ai

Firmware für micro:bit V1 und V2, fertige .hex zum Aufspielen, die Bluetooth-Brücke in Python, das vollständige Befehlsprotokoll und die Hardware-Dokumentation. MIT-Lizenz — nimm es, bau es um, mach es besser.

Wer einen Proxi zu Hause stehen hat: Die .hex kopierst du auf das MICROBIT-Laufwerk, danach braucht es nur noch einen Rechner mit Bluetooth.