L’IA può trasformare la tua mano nel comando di un dispositivo reale?

Immagina di tenere una mano sopra un sintetizzatore e chiedere al visore di associare l'altezza delle dita alla frequenza di taglio del filtro. Sai già cosa deve fare il gesto. La difficoltà sta nel collegare la mano in movimento alla manopola vera, soprattutto quando lo strumento parla MIDI e il visore vede solo una scatola sul tavolo.

ControlAnything, prototipo di ricerca descritto da Bektur Ryskeldiev in una prepubblicazione del 5 novembre 2026, sposta una parte dell'integrazione al momento in cui la chiedi. Chi indossa un Meta Quest 3 seleziona un oggetto, dà un'istruzione e attende che un agente su un MacBook scriva un connettore. Il risultato può essere un insieme di controlli virtuali, un programma che legge il movimento della mano o entrambi. Il progetto mette a disposizione codice e dimostrazioni, compresa una simulazione su desktop.

La registrazione su Quest 3 dell'autore Bektur Ryskeldiev mostra i controlli generati per l'OP-1 Field durante la prova. Telli.sh ha ridimensionato il fotogramma. Prepubblicazione e fotogramma originale · Avviso di licenza MIT per il video

Il risultato interessante è che il visore può creare un nuovo comando per un compito preciso. La domanda aperta riguarda come il sistema sappia che cosa è successo. Una conferma MIDI, una manopola virtuale che risponde e un sintetizzatore che cambia suono sono tre prove distinte.

Indicare un dispositivo avvia la richiesta

Il prototipo combina un client WebXR, un server sul portatile, un agente di programmazione e alcuni canali verso i dispositivi. SAM 3.1 delinea gli oggetti possibili nella vista del visore. Un gesto a pinza può contrassegnarne uno e Muse Spark può suggerire che oggetto sia. La prepubblicazione tratta l'identità suggerita come un'ipotesi da confrontare con indizi quali il nome di una porta MIDI o una risposta del dispositivo. L'etichetta permette alla persona di indicare un obiettivo. La porta, il bridge del browser o il componente che invia i tasti consentono al portatile di agire. Prepubblicazione ControlAnything, sezioni 3 e 4

Dall'obiettivo selezionato a un risultato visibile o udibile. Illustrazione originale di Telli.sh.

Pensa al contrassegno come a un'etichetta per bagagli. Serve a identificare quello che vuoi spostare. Itinerario e destinazione sono ancora da stabilire. La sessione del 5 novembre lo mostra bene. Tutte le richieste erano rivolte all'etichetta del MacBook che l'autore aveva creato prima. Se il bersaglio era il sintetizzatore OP-1 Field o lo stabilizzatore DJI Osmo Mobile 4, l'autore lo nominava nella richiesta. La sessione riguarda quindi dispositivi che l'ambiente sapeva già raggiungere. Selezionare un sintetizzatore o uno stabilizzatore sconosciuto rimane una prova da fare.

Il sistema disponeva anche di dettagli utili prima del primo gesto. Il progetto documenta canali MIDI, Bluetooth e di pressione dei tasti. Nelle note conservate dall'agente c'erano già il nome della porta dell'OP-1, i numeri di controllo del filtro e le istruzioni per muovere lo stabilizzatore. Una foto può suggerire che un oggetto sia un sintetizzatore. I dettagli precedenti dicono al programma quale valore inviare, dove mandarlo e come mantenerlo nell'intervallo voluto.

Il modello crea il comando una volta e il programma gestuale gira più volte

Il prototipo separa il lavoro costoso di generare un'interazione da quello ripetuto di eseguirla. Una richiesta parlata viene trascritta, l'agente scrive un connettore e il server verifica che sia in esecuzione e che ogni controllo restituito sia associato a un'azione dichiarata. Il programma gestuale legge segnali dalle articolazioni a ogni fotogramma ed emette valori o eventi. Il modello interviene durante la configurazione. Il visore esegue il programma mentre ti muovi. Implementazione nella prepubblicazione

La differenza conta per un comando continuo, come il suono o l'inquadratura. Se un modello linguistico dovesse decidere ogni nuovo valore, ogni fotogramma diventerebbe un'altra decisione lenta. Un piccolo programma può invece associare l'altezza della mano a un parametro, limitarne l'intervallo e reagire a un rilascio. Per un'azione come passare al video successivo, può richiedere un gesto deliberato e aspettare che la mano torni in posizione neutra prima di riattivarsi. Sono esempi delle possibilità offerte dall'approccio, senza descrivere risultati misurati nel prototipo.

La prepubblicazione indica un tempo di preparazione mediano di 32,5 secondi per le nove richieste arrivate allo stato pronto, con valori tra 24,9 e 57,8 secondi. La misurazione parte da quando il server gestisce la richiesta ed esclude la trascrizione. Le chiamate al modello hanno rappresentato una mediana dell'89,9% di quel tempo. L'autore precisa inoltre che la sessione non ha misurato il tempo fra il movimento della mano e la risposta del dispositivo. Risultati della prepubblicazione

Così si può dare un costo concreto alla flessibilità. Mezzo minuto può andare bene se sostituisce un connettore che richiederebbe un pomeriggio di lavoro e che useresti per tutta una prova. È più difficile da giustificare se il gesto serve a svolgere un compito da cinque secondi con il telecomando esistente. Il caso interessante è quello in cui il comando torna utile molte volte, anche se la persona lo configura una sola volta.

I risultati suggeriscono un passo successivo. Due richieste per interazioni simili con acqua simulata hanno impiegato 31,6 e 32,5 secondi perché ciascuna ha generato un nuovo connettore. Il 91,7% dei token di input della sessione proveniva dalla cache del prompt, ma non è stato recuperato un comando precedente pronto all'uso. Salvare un'associazione già verificata e lasciare che l'utente scelga quando riusarla affronta una parte diversa del costo di preparazione. Il controllo delle versioni diventerebbe importante perché il connettore riusato richiede le stesse condizioni di dispositivo, account e intervallo in cui è stato provato.

Un filtro, uno stabilizzatore e un browser richiedono verifiche diverse

Alla sessione del 5 novembre ha partecipato una sola persona, l'autore. Ha fatto dieci richieste su cinque bersagli. Nove sono arrivate allo stato pronto e la persona ha fermato l'altra. L'esperimento era tecnico ed esplorativo. Le richieste erano formulate liberamente, alcune ripetevano obiettivi precedenti e il sistema disponeva di conoscenze pregresse sui dispositivi. Il conteggio racconta ciò che è accaduto in quella sessione. La probabilità che una persona alla prima prova colleghi un dispositivo sconosciuto richiede una misura diversa. Tabella e metodo della prepubblicazione

Una conferma del canale di comunicazione e un effetto misurato rispondono a domande diverse. Illustrazione originale di Telli.sh.

Considera il sintetizzatore. MIDI può trasmettere un comando di filtro ben formato mentre lo strumento usa un'impostazione sonora che risponde diversamente o ha disattivato la ricezione MIDI. La prepubblicazione descrive un caso precedente in cui i messaggi erano confermati, ma lo strumento è rimasto muto finché la ricezione non è stata attivata. Una variazione udibile, registrata a partire da una nota di prova nota, dice più di un'altra copia dello stesso messaggio di log.

Lo stabilizzatore mostra lo stesso principio in un altro modo. Il bridge ha registrato 889 risposte riuscite a comandi di rotazione durante la sessione, comprese quelle di arresto e rilascio. Ciò indica che il canale ha accettato comandi durante un'interazione prolungata. I log non contenevano un angolo affidabile. In una prova successiva potresti scegliere un obiettivo sicuro e confrontare l'angolo richiesto con un video o un segno di riferimento. Potresti così capire se il movimento è stato preciso, ripetibile e limitato come previsto.

La tastiera aggiunge un problema di identità. La pressione di un tasto può riuscire a livello del sistema operativo e raggiungere comunque la finestra sbagliata. Una prova del browser dovrebbe controllare la scheda attiva, verificare che sia cambiato il contenuto previsto e accertarsi che le altre finestre siano rimaste intatte. Quanto più astratta è l'interfaccia del connettore, tanto più è utile stabilire cosa significhi aver finito.

L'arresto deve funzionare prima di potersi fidare del gesto

Il percorso di arresto di ControlAnything è indipendente dal modello. La persona può fermare la generazione, mostrare entrambi i palmi durante l'uso o usare un comando nel menu al polso. L'host può ritirare il connettore e inviare rilasci neutri, per esempio fermando lo stabilizzatore o liberando lo stato MIDI. L'implementazione esegue il programma gestuale del visore in un worker con restrizioni e ne controlla il comportamento su 480 fotogrammi sintetici prima di distribuirlo. Limita anche le azioni dichiarate e gli intervalli che il programma può emettere. Sicurezza e arresto nella prepubblicazione

Il connettore sul portatile si trova in una situazione diversa. La prepubblicazione lo descrive come un comune processo Node con i permessi dell'utente del portatile. Il prototipo non isola quel processo generato. L'SDK può limitare i comandi che passano dal canale previsto, mentre un connettore capace di eseguire codice generico conserva i poteri dell'account che lo avvia. Una versione affidabile per la produzione metterebbe quei privilegi sotto il controllo del sistema operativo e limiterebbe l'accesso ai dispositivi necessari per la richiesta.

Immagina un'installazione con due meccanismi in movimento. Un'interfaccia che ne etichetta uno solo può sembrare rassicurante, ma conta se il connettore possa comunque trovare l'altro e azionarlo. In una dimostrazione sicura, l'unico bersaglio raggiungibile è quello in prova. L'arresto si verifica separatamente, chi opera ha spazio per allontanarsi e la prova mostra che cosa succede se il tracciamento si perde o un dispositivo si scollega.

La stessa distinzione vale per il codice generato che legge l'ambiente. Il prototipo indica al modello di trattare il testo nelle immagini o nelle risposte degli strumenti come dati. L'istruzione può orientarne il comportamento. I permessi di processo e i canali disponibili determinano ciò che un errore può raggiungere. Per chi prova il prototipo sono questioni distinte da chiarire prima di esporre il portatile a dispositivi reali o account attivi.

Parti da un bersaglio simulato e mantieni piccola la prova

Il README del progetto descrive una simulazione desktop con Node 22.12 o successivo e Chrome. Secondo il progetto, senza chiave API il server riproduce risposte registrate in una modalità di prova chiaramente indicata. Puoi così esaminare il percorso dal bersaglio contrassegnato alle manopole generate prima di aggiungere visore, chiamate al modello o apparecchi fisici. Una prova con dati registrati mostra un percorso noto nell'interfaccia. Una valutazione dal vivo inizia quando cambi il bersaglio, il gesto o la risposta del modello. Istruzioni per la dimostrazione di ControlAnything

1. Leggi le istruzioni del repository ed esegui la simulazione documentata in un ambiente usa e getta. Apri il simulatore e l'emulatore desktop del visore, quindi contrassegna il portatile simulato che esegue il sintetizzatore virtuale.
2. Scegli la richiesta di manopole già predisposta e verifica che l'indicatore della modalità di prova sia visibile. Osserva come l'interfaccia mostra il bersaglio e quando diventano disponibili i controlli.
3. Muovi una manopola virtuale, verifica il cambiamento sul bersaglio simulato e prova il comando di arresto documentato. Tieni separato quello che vedi nell'interfaccia da quello che dicono i log del connettore.
4. Per una futura dimostrazione fisica, scegli un dispositivo a basso rischio e un comando reversibile. Annota l'esito atteso prima di inviare il comando. Prepara un modo indipendente per vedere o sentire la variazione e per arrestare il dispositivo.

Per un laboratorio, parti dal sintetizzatore visivo virtuale prima di usare una funzione che apre un servizio reale o preme tasti sulla macchina host. Il README distingue esplicitamente il percorso di Instagram Reels da quello simulato. Se vuoi capire come si associa il gesto al comando, un bersaglio locale circoscritto rende più chiaro il comportamento.

Quando passi all'hardware reale, misura a parte il tempo di preparazione e la qualità del controllo. Cronometra quanto impiega a essere pronto. Osserva il ritardo dal gesto all'effetto, eventuali spostamenti imprevisti quando la mano esce dall'area tracciata e cosa succede quando la persona cambia idea. Uno studio più lungo può rispondere a queste domande e verificare se chi non ha mai visto l'interfaccia scelga il bersaglio giusto senza aiuto.

Un comando utile si può creare e verificare

L'idea più forte di ControlAnything è lasciare che una persona descriva un'interazione fisica senza preparare prima un'interfaccia su misura. La valutazione mostra come funziona con un insieme di bersagli noti e un solo visore. Per riusare un comando servirà più di una connessione riuscita. Dovrà identificare il dispositivo, limitare la propria autorità e rendere l'effetto abbastanza visibile da consentire alla persona che indossa il visore di fidarsi di ciò che è accaduto.

Fonti

• Prepubblicazione di ControlAnything, presentata il 5 novembre 2026
• Implementazione completa, valutazione e limiti
• Repository del progetto, dimostrazioni e istruzioni del simulatore

---

Per ritrovare facilmente le note e le decisioni di una sessione di prototipazione, crea un account Telli.sh.