¿Puede una IA convertir tu mano en el mando de un dispositivo real?
ControlAnything escribe un conector cuando pides un gesto en realidad mixta. Un sintetizador, un estabilizador y una sesión con visor muestran qué puede demostrar el prototipo.
Imagina sostener la mano sobre un sintetizador y pedirle a un visor que asocie la altura de tus dedos con la frecuencia de corte del filtro. Ya sabes qué debe hacer el gesto. Lo difícil es conectar una mano en movimiento con el mando real, sobre todo cuando el instrumento habla MIDI y el visor solo ve una caja encima de una mesa.
ControlAnything, un prototipo de investigación descrito por Bektur Ryskeldiev en una prepublicación del 5 de noviembre de 2026, traslada parte de esa integración al momento en que la pides. Quien lleva un Meta Quest 3 selecciona un objetivo, da una instrucción y espera a que un agente en un MacBook escriba un conector. El resultado puede ser un conjunto de controles virtuales, un programa que lea el movimiento de la mano o ambos. El proyecto ofrece código y demostraciones, incluida una simulación de escritorio.
La grabación de Quest 3 del autor, Bektur Ryskeldiev, muestra los controles del OP-1 Field generados durante la evaluación. Telli.sh redimensionó el fotograma. Prepublicación y fotograma original · Aviso de licencia MIT del vídeo
El resultado interesante es que el visor puede crear un control nuevo para una tarea concreta. La incógnita está en cómo sabe el sistema qué ha ocurrido. Una confirmación MIDI, un mando virtual que responde y un sintetizador cuyo sonido cambia son tres pruebas distintas.
Señalar un dispositivo pone en marcha la petición
El prototipo combina un cliente WebXR, un servidor en el portátil, un agente de programación y unas pocas vías para llegar a los dispositivos. SAM 3.1 delimita objetos posibles en la vista del visor. Un gesto de pinza puede convertir uno en una etiqueta y Muse Spark puede sugerir de qué objeto se trata. La prepublicación considera esa identidad una hipótesis que se puede contrastar con datos como el nombre de un puerto MIDI o una respuesta del dispositivo. La etiqueta permite referirse al objetivo. El puerto, el puente del navegador o el componente que pulsa teclas permiten al portátil actuar sobre él. Prepublicación de ControlAnything, secciones 3 y 4
Del objetivo seleccionado al resultado visible o audible. Ilustración original de Telli.sh.
Piensa en la etiqueta como en la de una maleta. Sirve para nombrar lo que quieres mover. El trayecto y el destino todavía están por establecer. La sesión del 5 de noviembre lo deja claro. Todas las peticiones se dirigieron a la etiqueta del MacBook, creada antes por el autor. Si el objetivo era el sintetizador OP-1 Field o el estabilizador DJI Osmo Mobile 4, el autor lo nombraba en la petición. La sesión muestra cómo se conectaron dispositivos a los que el entorno ya sabía llegar. Seleccionar un sintetizador o estabilizador desconocido queda como prueba abierta.
Antes del primer gesto, el sistema ya contaba con información útil. El proyecto documenta vías MIDI, Bluetooth y de pulsación de teclas. Las notas del agente ya incluían el puerto del OP-1, los números de control del filtro y las instrucciones para mover el estabilizador. Una imagen puede sugerir que algo parece un sintetizador. Los datos anteriores indican al programa qué valor enviar, dónde enviarlo y cómo mantenerlo en el intervalo previsto.
El modelo crea el control una vez y el programa gestual se ejecuta repetidamente
El prototipo separa el trabajo costoso de generar una interacción del trabajo repetido de ejecutarla. Transcribe una petición hablada, el agente escribe un conector y el servidor comprueba que esté en marcha y que cada control devuelto esté vinculado a una acción declarada. El programa gestual lee señales de las articulaciones en cada fotograma y emite valores o eventos. El modelo interviene en la configuración. El visor ejecuta el programa mientras te mueves. Implementación en la prepublicación
La diferencia importa en un control continuo como el sonido o el encuadre. Si un modelo de lenguaje decidiera cada valor nuevo, cada fotograma implicaría otra decisión lenta. Un programa pequeño puede asociar la altura de la mano a un parámetro, limitar el intervalo y reaccionar cuando se suelta. Para una acción como avanzar un vídeo, puede exigir un gesto deliberado y esperar a que la mano vuelva a su posición neutra antes de activarse de nuevo. Son ejemplos de lo que permite explorar el enfoque, sin describir resultados medidos en el prototipo.
La prepublicación cifra la mediana de preparación en 32,5 segundos para las nueve peticiones que quedaron listas, con un intervalo de 24,9 a 57,8 segundos. La medición empieza cuando el servidor atiende la petición y excluye la transcripción del habla. Las llamadas al modelo representaron una mediana del 89,9 % de ese tiempo. El autor también indica que la sesión no midió el tiempo transcurrido entre el movimiento de la mano y la respuesta del dispositivo. Resultados de la prepublicación
Eso permite ponerle un coste a la flexibilidad. Medio minuto puede ser aceptable si sustituye a un conector que te llevaría una tarde escribir y que luego usarías durante todo un ensayo. Cuesta más justificarlo si el gesto controla una tarea que ya puedes resolver en cinco segundos con el mando existente. La oportunidad está en las tareas en las que el control resulta útil muchas veces, aunque solo se configure una.
Los resultados apuntan a otro paso práctico. Dos peticiones para interacciones similares con agua simulada tardaron 31,6 y 32,5 segundos porque cada una generó un conector nuevo. La caché de instrucciones sirvió el 91,7 % de los tokens de entrada de la sesión, pero no recuperó un control anterior listo para usar. Guardar una asignación revisada y dejar que la persona decida cuándo reutilizarla abordaría otra parte del coste de preparación. También haría importante registrar versiones, porque el conector reutilizado necesita las mismas condiciones de dispositivo, cuenta e intervalo para las que se probó.
Un filtro, un estabilizador y un navegador requieren comprobaciones distintas
En la sesión del 5 de noviembre participó una sola persona, el autor. Hizo diez peticiones para cinco objetivos. Nueve quedaron listas y la persona detuvo la otra. La prueba era técnica y exploratoria. Las peticiones se formularon libremente, algunas repetían objetivos y el entorno ya conocía los dispositivos. La cifra describe lo ocurrido en esa sesión. La probabilidad de que alguien nuevo conecte un dispositivo desconocido requiere otra medición. Tabla y método de la prepublicación
| Ejemplo de la sesión | Qué produjo el control generado | Qué permite comprobar que funcionó |
|---|---|---|
| Filtro del OP-1 Field | La petición de mandos de filtro devolvió dos controles por MIDI | Un cambio en la salida del instrumento, grabado con una entrada controlada o escuchado por una persona |
| DJI Osmo Mobile 4 | Un programa gestual y cuatro controles llegaron al estabilizador por un puente Bluetooth | Un movimiento observado o una lectura de posición verificada dentro del recorrido previsto |
| Instagram Reels en Chrome | La petición devolvió un programa gestual y tres controles mediante pulsaciones simuladas | Cambia la pestaña o el elemento previsto y las demás ventanas siguen intactas |
Una confirmación del canal de comunicación y un efecto medido responden a preguntas distintas. Ilustración original de Telli.sh.
Piensa en el sintetizador. MIDI puede transportar una orden de filtro bien formada aunque el instrumento use un ajuste de sonido que responda de otra forma o tenga desactivada la recepción MIDI. La prepublicación describe un caso anterior en que los mensajes se confirmaban y aun así no sonaba nada hasta activar la recepción. Un cambio audible, grabado frente a una nota de prueba conocida, aporta más que otra copia del mismo mensaje de registro.
El estabilizador enseña algo parecido. En la sesión, el puente registró 889 respuestas correctas a órdenes de giro, incluidas las de parada y liberación. Eso indica que el canal aceptó órdenes durante una interacción prolongada. El registro no contenía un ángulo fiable. En otra prueba, podrías fijar un objetivo seguro y comparar el ángulo pedido con un vídeo o una marca de referencia. Así podrías determinar si el movimiento fue preciso, repetible y limitado como se pretendía.
El teclado añade un problema de identidad. Una pulsación puede tener éxito en el sistema operativo y llegar a la ventana equivocada. Una prueba de navegador debe comprobar la pestaña activa, que cambió el contenido esperado y que las demás ventanas quedaron intactas. Cuanto más abstracta sea la interfaz del conector, más útil resulta definir qué significa que una acción haya terminado.
La parada tiene que funcionar antes de confiar en el gesto
La vía de parada de ControlAnything funciona sin depender del modelo. La persona puede detener la generación, mostrar ambas palmas durante el uso o recurrir a un control del menú de muñeca. El equipo anfitrión puede retirar el conector y enviar órdenes neutras, como detener el estabilizador o liberar el estado MIDI. La implementación ejecuta el programa gestual del visor en un proceso de trabajo restringido y comprueba su comportamiento con 480 fotogramas sintéticos antes de desplegarlo. También limita las acciones declaradas y los intervalos que puede emitir. Seguridad y parada en la prepublicación
El conector del portátil está en otra situación. La prepublicación lo describe como un proceso normal de Node que se ejecuta con los permisos del usuario del portátil. El prototipo no aísla ese proceso generado. El SDK puede limitar las órdenes que pasan por la vía admitida. Un conector que ejecuta código de propósito general conserva las facultades de la cuenta que lo ejecuta. Una versión fiable para producción sometería esos permisos al control del sistema operativo y restringiría el acceso a los dispositivos necesarios para la petición.
Imagina una instalación con dos mecanismos móviles. Una interfaz que solo etiqueta uno puede parecer tranquilizadora. Importa si el conector todavía puede descubrir el otro y actuar sobre él. Una demostración segura prepara un entorno en el que solo es accesible el objetivo de prueba. Comprueba la parada de forma independiente, deja al operador espacio para apartarse y muestra qué ocurre si se pierde el seguimiento o se desconecta un dispositivo.
La misma distinción se aplica al código generado que lee su entorno. El prototipo pide al modelo que trate el texto de las imágenes de cámara o las respuestas de herramientas como datos. Esa instrucción puede orientar su conducta. Los permisos del proceso y los canales disponibles determinan a qué puede afectar un error. Para probar el prototipo, son cuestiones distintas que conviene resolver antes de exponer el portátil a dispositivos reales o cuentas activas.
Empieza con un objetivo simulado y una prueba pequeña
El README del proyecto documenta una simulación de escritorio con Node 22.12 o superior y Chrome. Según el proyecto, sin clave de API el servidor reproduce respuestas grabadas en un modo de prueba identificado en pantalla. Así puedes ver el recorrido desde el objetivo etiquetado hasta los mandos generados antes de añadir un visor, llamadas al modelo o equipos físicos. Una prueba con datos grabados muestra un recorrido conocido por la interfaz. Una evaluación en directo empieza cuando cambias el objetivo, el gesto o la respuesta del modelo. Instrucciones de demostración de ControlAnything
- Lee las instrucciones del repositorio y ejecuta la simulación documentada en un entorno desechable. Abre el simulador y el emulador de visor para escritorio. Etiqueta el portátil simulado que ejecuta el sintetizador virtual.
- Elige la petición de mandos incluida y comprueba que se vea el indicador del modo de prueba. Observa cómo representa la interfaz el objetivo y cuándo quedan disponibles los controles.
- Mueve un mando virtual, comprueba el cambio en el objetivo simulado y prueba la parada documentada. Separa lo que observas en la interfaz de lo que dicen los registros del conector.
- Para una futura demostración física, elige un dispositivo de bajo riesgo y un control reversible. Anota el resultado esperado antes de enviar la orden. Prepara una vía independiente para ver u oír el cambio y detener el dispositivo.
En un taller, empieza con el sintetizador visual virtual antes que con una función que abra un servicio real o pulse teclas en el equipo anfitrión. El README distingue expresamente la vía de Instagram Reels del ejemplo simulado. Si quieres entender la asignación del gesto, un objetivo local acotado te da una imagen más clara.
Al pasar a equipos reales, mide por separado el tiempo de preparación y la calidad del control. Cronometra cuánto tarda en quedar listo. Observa el retardo del gesto al efecto, posibles desviaciones cuando la mano sale del área de seguimiento y lo que ocurre si la persona cambia de opinión. Un estudio más largo puede responder a esas preguntas y comprobar si alguien que nunca ha visto la interfaz elige el objetivo correcto sin ayuda.
Un control útil se puede crear y verificar
La mejor idea de ControlAnything es dejar que una persona describa una interacción física sin preparar primero una interfaz a medida. La evaluación muestra cómo funciona con objetivos conocidos y un solo visor. Un control reutilizable necesitará algo más que una conexión correcta. Debería identificar el dispositivo, limitar sus propios permisos y hacer visible el efecto para que la persona que lleva el visor pueda confiar en lo ocurrido.
Fuentes
- Prepublicación de ControlAnything, presentada el 5 de noviembre de 2026
- Implementación completa, evaluación y límites
- Repositorio del proyecto, demostraciones e instrucciones del simulador
Para tener a mano las notas y decisiones de una sesión de prototipado, crea una cuenta en Telli.sh.