Kann eine KI Ihre Hand zur Fernsteuerung eines echten Geräts machen?

Stellen Sie sich vor, Sie halten die Hand über einen Synthesizer und bitten ein Headset, die Höhe Ihrer Finger auf die Grenzfrequenz des Filters abzubilden. Was die Geste bewirken soll, steht fest. Schwierig ist die Verbindung zwischen der bewegten Hand und dem tatsächlichen Regler, besonders wenn das Instrument MIDI spricht und das Headset nur einen Kasten auf einem Tisch sieht.

ControlAnything ist ein Forschungsprototyp aus einem Preprint von Bektur Ryskeldiev vom 5. November 2026. Er verlagert einen Teil der Integrationsarbeit in den Moment, in dem sie gebraucht wird. Eine Person wählt in der Ansicht einer Meta Quest 3 ein Ziel aus, gibt eine Anweisung und wartet, während ein Agent auf einem MacBook die Anbindung programmiert. Als Bedienelemente können virtuelle Regler, ein Programm für Handbewegungen oder beides zurückkommen. Das Projekt bietet Code und Demos, darunter eine Desktop-Simulation.

Die Quest-3-Aufnahme des Autors Bektur Ryskeldiev zeigt in der Untersuchung erzeugte Regler für den OP-1 Field. Telli.sh hat das Standbild skaliert. Preprint und Originalbild · MIT-Lizenzhinweis zum Projektvideo

Das Headset kann eine neue Steuerung für eine bestimmte Aufgabe erzeugen. Offen bleibt, woher das System weiß, was tatsächlich passiert ist. Eine MIDI-Bestätigung, ein reagierender virtueller Regler und ein hörbar veränderter Synthesizer liefern drei unterschiedliche Belege.

Zeigen auf ein Gerät leitet die Anfrage ein

Der Prototyp verbindet einen WebXR-Client, einen Server auf dem Laptop, einen Programmieragenten und einige Wege zu den Geräten. SAM 3.1 umrandet mögliche Objekte in der Headset-Ansicht. Eine Greifgeste kann daraus eine Markierung machen, und Muse Spark kann vorschlagen, um welches Objekt es sich handelt. Der Preprint behandelt den Vorschlag als Hypothese, die sich etwa mit einem MIDI-Portnamen oder einer Geräteantwort abgleichen lässt. Mit der Markierung kann die Person auf ein Ziel verweisen. Erst der Port, die Browser-Brücke oder die Tastatureingabe erlaubt dem Laptop, darauf einzuwirken. ControlAnything-Preprint, Abschnitte 3–4

Vom ausgewählten Ziel zum sichtbaren oder hörbaren Ergebnis. Eigene Illustration von Telli.sh.

Eine Markierung ist wie ein Gepäckanhänger. Sie benennt, was bewegt werden soll, während Strecke und Ziel noch feststehen müssen. Die Sitzung des Prototyps am 5. November macht den Unterschied deutlich. Jede Anfrage ging an die Markierung des MacBooks, die der Autor vorher angelegt hatte. Wenn eigentlich der Synthesizer OP-1 Field oder der Gimbal DJI Osmo Mobile 4 gemeint war, nannte er das Gerät in der Anfrage. Die Sitzung zeigt also, wie die Anbindung bei Geräten funktioniert, die der Aufbau schon erreichen konnte. Die Auswahl eines unbekannten Synthesizers oder Gimbals bleibt offen.

Vor der ersten Geste lagen bereits hilfreiche Informationen vor. Das Projekt dokumentiert MIDI, Bluetooth und simulierte Tastendrücke. Die gespeicherten Notizen des Agenten enthielten vor der Sitzung bereits den Portnamen des OP-1, die Nummern der Filter-Controller und Hinweise zur Gimbal-Steuerung. Ein Kamerabild kann nahelegen, dass etwas ein Synthesizer ist. Die vorbereiteten Angaben verraten dem Programm, welcher Wert wohin gehört und in welchem Bereich er bleiben soll.

Das Modell erstellt die Steuerung einmal, das Handprogramm läuft fortlaufend

Der Prototyp trennt die aufwendige Erzeugung der Interaktion von ihrer wiederholten Ausführung. Eine gesprochene Anfrage wird transkribiert. Der Agent schreibt eine Anbindung, und der Server prüft, ob sie läuft und ob jedes zurückgelieferte Bedienelement an eine deklarierte Aktion gebunden ist. Das entstandene Programm liest in jedem Frame Signale aus den Handgelenk- und Fingerpositionen und gibt Werte oder Ereignisse aus. Das Modell arbeitet bei der Einrichtung. Das Headset führt das erzeugte Programm bei der Bewegung aus. Implementierung im Preprint

Für fortlaufende Steuerungen wie Klang oder Kamerarahmen ist das wichtig. Wenn ein Sprachmodell jeden neuen Wert wählen müsste, würde jedes Bild eine weitere langsame Entscheidung auslösen. Ein kleines Programm kann die Handhöhe einem Parameter zuordnen, den Wertebereich begrenzen und auf das Loslassen reagieren. Beim Weiterblättern in einem Video könnte es eine bewusste Geste verlangen und erst wieder reagieren, nachdem die Hand zur neutralen Haltung zurückgekehrt ist. Solche Zuordnungen illustrieren mögliche Entwürfe. Sie sind keine Messergebnisse des Prototyps.

Laut Preprint lag der Median der Einrichtung bei 32,5 Sekunden für die neun Anfragen, die bereit wurden. Die Spanne reichte von 24,9 bis 57,8 Sekunden. Gemessen wurde ab der Bearbeitung durch den Server, ohne Sprachtranskription. Modellaufrufe beanspruchten im Median 89,9 Prozent dieser Zeit. Die Zeit von der Bewegung bis zur Reaktion des Geräts wurde laut Autor nicht gemessen. Ergebnisse des Preprints

So bekommt die Flexibilität einen greifbaren Preis. Eine halbe Minute kann sich lohnen, wenn sie eine Anbindung ersetzt, die sonst einen Nachmittag Entwicklungszeit kosten würde und die ganze Probe im Einsatz bleibt. Bei einer Aufgabe, die mit der vorhandenen Fernbedienung fünf Sekunden dauert, ist die Wartezeit schwerer zu rechtfertigen. Der mögliche Gewinn liegt bei Aufgaben, deren Steuerung wiederholt wertvoll ist, obwohl sie nur einmal eingerichtet wird.

Zwei ähnliche Anfragen zur Wassersimulation dauerten 31,6 und 32,5 Sekunden, weil beide eine neue Anbindung erzeugten. Der Prompt-Cache lieferte 91,7 Prozent der Eingabetokens der Sitzung, trotzdem wurde der frühere Konnektor nicht als fertige Steuerung wiederverwendet. Eine geprüfte Zuordnung zu speichern und der Person die Wiederverwendung anzubieten, würde einen anderen Teil des Aufwands senken. Dann wird die Versionsverwaltung wichtig, weil bei einem wiederverwendeten Konnektor Gerät, Konto und Wertebereich noch zur geprüften Konfiguration passen müssen.

Filterregler, Gimbal und Browser brauchen unterschiedliche Nachweise

In der Sitzung am 5. November nutzte nur der Autor das Headset. Es gab zehn Anfragen für fünf Ziele. Neun wurden bereit, und die verbleibende stoppte er selbst. Das war eine technische Erkundung. Die Anfragen waren frei formuliert, manche wiederholten ein früheres Ziel, und der Aufbau verfügte über Vorwissen zu den Geräten. Die Zahl beschreibt den Verlauf dieser einen Sitzung. Wie wahrscheinlich eine neue Person ein unbekanntes Gerät verbinden kann, wäre separat zu messen. Tabelle und Methode des Preprints

Eine Transportbestätigung und eine gemessene Wirkung beantworten unterschiedliche Fragen. Eigene Illustration von Telli.sh.

MIDI kann beim Synthesizer einen gültigen Filterbefehl übertragen, während das aktuelle Klangprogramm anders reagiert oder der MIDI-Empfang deaktiviert ist. Der Preprint beschreibt einen früheren Fall, in dem bestätigte Nachrichten ohne hörbare Wirkung blieben, bis der Empfang eingeschaltet wurde. Ein hörbarer Unterschied bei einer bekannten Testnote wäre aussagekräftiger als eine zweite Kopie derselben Protokollmeldung.

Beim Gimbal zeigt sich dasselbe in anderer Form. Die Brücke protokollierte 889 erfolgreiche Antworten auf Drehbefehle einschließlich Stopp- und Freigabebefehlen. Das belegt, dass über längere Zeit Befehle angenommen wurden. Die Protokolle enthielten keinen verlässlichen Winkel. In einem Folgeversuch ließe sich eine sichere Zielposition definieren und der angeforderte Winkel mit einem Video oder einer Referenzmarke abgleichen. Erst dann wäre sichtbar, ob die Bewegung genau, wiederholbar und wie vorgesehen begrenzt war.

Bei der Tastatursteuerung kommt hinzu, welches Fenster das Ziel ist. Ein Tastendruck kann im Betriebssystem erfolgreich sein und dennoch im falschen Fenster ankommen. Ein Browsertest sollte den aktiven Tab prüfen, die erwartete Änderung bestätigen und sicherstellen, dass andere Fenster unberührt bleiben. Je abstrakter die Schnittstelle, desto nützlicher ist ein klares Kriterium dafür, wann die Aufgabe erledigt ist.

Die Stoppfunktion muss zuverlässig sein

Der Stoppmechanismus von ControlAnything ist unabhängig vom Modell. Die Person kann die Generierung stoppen, während der Nutzung beide Handflächen zeigen oder eine Funktion im Handgelenkmenü verwenden. Der Host kann die Anbindung beenden und neutrale Signale senden, etwa den Gimbal stoppen oder den MIDI-Zustand freigeben. Das Handprogramm läuft auf dem Headset in einem eingeschränkten Worker. Vor der Bereitstellung wird es mit 480 synthetischen Frames geprüft. Die Implementierung begrenzt die erlaubten Aktionen und Wertebereiche. Sicherheit und Stoppmechanismen im Preprint

Die Laptop-Anbindung ist anders aufgebaut. Der Preprint beschreibt einen gewöhnlichen Node-Prozess mit den Berechtigungen des Laptop-Nutzers. Dieser erzeugte Prozess läuft im Prototyp ohne Sandbox. Das SDK kann Befehle auf dem vorgesehenen Weg begrenzen. Kann ein Konnektor beliebigen Code ausführen, behält er jedoch die Berechtigungen des Kontos, unter dem er läuft. Eine verlässliche Produktionsversion würde diese Rechte auf Betriebssystemebene beschränken und nur die für die Anfrage nötigen Geräte erreichbar machen.

Stellen Sie sich eine Installation mit zwei beweglichen Vorrichtungen vor. Die Oberfläche zeigt beruhigenderweise nur eine davon an. Entscheidend bleibt, ob der Konnektor die andere erkennen und steuern kann. Bei einer sicheren Vorführung ist nur das Testziel erreichbar. Der Stopp wird unabhängig geprüft, die Bedienperson kann Abstand nehmen, und der Aufbau zeigt, was bei verlorenem Tracking oder getrennter Geräteverbindung passiert.

Das gilt auch für erzeugten Code, der Informationen aus der Umgebung liest. Der Prototyp weist das Modell an, Text in Kamerabildern oder Werkzeugantworten als Daten zu behandeln. Die Anweisung kann das Verhalten lenken. Welche Auswirkungen ein Fehler hat, bestimmen die Prozessrechte und verfügbaren Verbindungswege. Wer den Prototyp ausprobiert, sollte beide Fragen klären, bevor echte Geräte oder aktive Konten hinzukommen.

Beginnen Sie mit einem simulierten Ziel und halten Sie den Test klein

Das Projekt-README dokumentiert eine Desktop-Simulation mit Node 22.12 oder neuer und Chrome. Ohne API-Schlüssel spielt der Server laut Projekt aufgezeichnete Antworten in einem sichtbar gekennzeichneten Testmodus ab. So lässt sich der Weg von der Markierung zu den erzeugten Reglern ansehen, bevor Headset, Modellaufrufe oder physische Geräte hinzukommen. Der Testmodus zeigt einen bekannten Ablauf. Eine Live-Auswertung beginnt, wenn Sie das Ziel, die Geste oder die Modellantwort ändern. Anleitung zur ControlAnything-Demo

1. Lesen Sie die Anweisungen im Repository und starten Sie die Simulation in einer entbehrlichen Umgebung. Öffnen Sie Simulator und Desktop-Headset-Emulator. Markieren Sie den simulierten Laptop, auf dem der virtuelle Synthesizer läuft.
2. Wählen Sie die vorbereitete Regleranfrage und prüfen Sie, ob die Kennzeichnung des Testmodus sichtbar ist. Beobachten Sie, wie die Oberfläche das gewählte Ziel darstellt und wann die Regler verfügbar werden.
3. Bewegen Sie einen virtuellen Regler, bestätigen Sie die Wirkung am simulierten Ziel und testen Sie den dokumentierten Stopp. Halten Sie Beobachtungen der Oberfläche und Konnektorprotokolle getrennt.
4. Wählen Sie für eine spätere physische Demo ein Gerät mit geringem Risiko und einer umkehrbaren Aktion. Notieren Sie das erwartete Ergebnis vor dem Befehl. Sorgen Sie für einen unabhängigen Weg, die Wirkung zu sehen oder zu hören und das Gerät zu stoppen.

Beginnen Sie bei einem Workshop mit dem virtuellen Synthesizer, bevor eine Funktion einen echten Dienst öffnet oder auf dem Host Tasten drückt. Das Projekt-README unterscheidet den Instagram-Reels-Weg ausdrücklich von der Simulation. Wenn die Zuordnung im Mittelpunkt steht, liefert ein begrenztes lokales Testziel ein klareres Bild.

Messen Sie bei echter Hardware Einrichtungszeit und Steuerqualität separat. Erfassen Sie die Zeit bis zur Bereitschaft, die Verzögerung bis zur Wirkung, mögliche Abweichungen beim Verlassen des Erfassungsbereichs und das Verhalten bei einem Meinungswechsel. Eine längere Studie könnte auch klären, ob jemand ohne Vorerfahrung das richtige Ziel ohne Hilfe auswählt.

Eine brauchbare Steuerung lässt sich erstellen und überprüfen

Die zentrale Idee von ControlAnything ist, dass eine Person eine physische Interaktion beschreiben kann, ohne vorher eine spezielle Oberfläche zu bauen. Die Untersuchung zeigt das auf einer bekannten Gruppe von Zielen mit einem einzigen Headset. Für eine wiederverwendbare Steuerung braucht es über die Verbindung hinaus eine eindeutige Geräteidentität, begrenzte Befugnisse und eine erkennbare Wirkung, auf die sich die Person mit dem Headset verlassen kann.

Quellen

• ControlAnything-Preprint, eingereicht am 5. November 2026
• Vollständige Implementierung, Untersuchung und Grenzen
• Projekt-Repository, Demos und Simulatoranleitung

---

Wenn Sie Notizen und Entscheidungen aus einer Prototypsitzung später leicht wiederfinden möchten, erstellen Sie ein Telli.sh-Konto.