Uma IA consegue transformar sua mão em controle para um aparelho real?
O ControlAnything escreve um conector quando você pede um gesto em realidade mista. Um sintetizador, um estabilizador e uma sessão com headset mostram o alcance do protótipo.
Imagine segurar a mão acima de um sintetizador e pedir ao headset que associe a altura dos dedos à frequência de corte do filtro. Você já sabe o que o gesto deve fazer. A parte difícil é ligar a mão em movimento ao controle real, especialmente quando o instrumento entende MIDI e o headset só enxerga uma caixa na mesa.
O ControlAnything, protótipo de pesquisa descrito em um preprint de Bektur Ryskeldiev de 5 de novembro de 2026, transfere parte da integração para o momento do pedido. A pessoa seleciona um alvo na visão do Meta Quest 3, dá uma instrução e espera um agente em um MacBook escrever o conector. Os controles retornados podem ser elementos virtuais, um programa que lê os movimentos da mão ou ambos. O projeto oferece código e demonstrações, inclusive uma simulação para computador.

A gravação do Quest 3 feita pelo autor Bektur Ryskeldiev mostra controles gerados para o OP-1 Field durante a avaliação. O Telli.sh redimensionou a imagem. Preprint e quadro original · Aviso de licença MIT do vídeo do projeto
O resultado interessante é que o headset consegue criar um controle para uma tarefa específica. A questão em aberto é como o sistema sabe o que aconteceu de fato. Uma confirmação MIDI, um botão virtual que responde e um sintetizador que muda de som são três evidências distintas.
Apontar para um aparelho inicia o pedido
O protótipo combina cliente WebXR, servidor em um notebook, agente de programação e algumas maneiras de chegar aos dispositivos. O SAM 3.1 contorna possíveis objetos na imagem do headset. Uma pinça com os dedos pode marcar um deles, e o Muse Spark pode sugerir o que ele é. O preprint trata essa identidade sugerida como hipótese, a comparar com evidências como o nome de uma porta MIDI ou a resposta do dispositivo. A marca permite indicar o alvo. A porta, a ponte com o navegador ou o executor de teclas é que permite ao notebook agir sobre ele. Preprint do ControlAnything, seções 3 e 4
Do alvo selecionado a um resultado visível ou audível. Ilustração original do Telli.sh.
Pense na marca como uma etiqueta de bagagem. Ela ajuda a nomear o que você quer movimentar. Ainda é preciso estabelecer o trajeto e o destino. Na sessão de 5 de novembro do protótipo, essa distinção fica clara. Todos os pedidos foram endereçados à marca do MacBook, que o autor já havia criado. Quando o alvo desejado era o sintetizador OP-1 Field ou o estabilizador DJI Osmo Mobile 4, o autor o nomeou no pedido. A sessão mostra como conectar aparelhos que a configuração já sabia alcançar. A seleção de um sintetizador ou estabilizador desconhecido fica para outro experimento.
O sistema também já tinha informações úteis antes do primeiro gesto. O projeto documenta comunicações por MIDI, Bluetooth e pressionamento de teclas. As anotações mantidas pelo agente já continham o nome da porta do OP-1, os números dos controles de filtro e instruções para mover o estabilizador. Uma imagem mostra que algo parece um sintetizador. As informações anteriores dizem ao programa que valor enviar, para onde e como mantê-lo dentro dos limites desejados.
O modelo constrói o controle uma vez e o programa da mão roda repetidamente
O protótipo separa o trabalho custoso de gerar uma interação da tarefa repetida de executá-la. O pedido falado é transcrito, o agente escreve um conector e o servidor verifica se ele está rodando e se cada controle retornado está associado a uma ação declarada. O programa da mão lê, a cada quadro, sinais derivados das articulações e emite valores ou eventos. O modelo trabalha na configuração. O headset executa o programa enquanto a pessoa se move. Implementação no preprint
A diferença importa em um controle contínuo, como o som ou o enquadramento da câmera. Se um modelo de linguagem precisasse decidir cada valor novo, todo quadro viraria mais uma decisão lenta. Um programa pequeno pode associar altura da mão a um parâmetro, respeitar os limites e responder quando o gesto é solto. Para um gatilho como avançar um vídeo, pode exigir um gesto deliberado e esperar que a mão volte à posição neutra antes de rearmar. Esses mapeamentos são exemplos das possibilidades, sem representar medições do protótipo.
O preprint relata tempo mediano de configuração de 32,5 segundos nos nove pedidos que ficaram prontos, com intervalo de 24,9 a 57,8 segundos. A contagem começa no tratamento do pedido pelo servidor e exclui a transcrição de fala. As chamadas ao modelo representaram uma mediana de 89,9% do tempo de configuração. O autor também informa que a sessão não mediu o tempo entre o movimento da mão e a resposta do dispositivo. Resultados do preprint
Isso dá uma medida útil do custo da flexibilidade. Meio minuto pode ser aceitável se substituir um conector que tomaria uma tarde para escrever e seria usado durante todo um ensaio. É mais difícil justificar a espera quando o controle existente resolve a tarefa em cinco segundos. A oportunidade mais provável é uma ação cujo controle tem valor repetidas vezes, mesmo que a pessoa só o configure uma vez.
Os resultados sugerem um próximo passo. Dois pedidos para interações parecidas em uma simulação de água levaram 31,6 e 32,5 segundos porque cada um gerou um novo conector. O cache de prompts atendeu 91,7% dos tokens de entrada da sessão, mas um conector anterior não virou um controle pronto para reutilizar. Salvar um mapeamento revisado e deixar a pessoa escolher quando reaproveitá-lo trataria outra parte do custo de configuração. O versionamento também passaria a importar, porque o conector reutilizado depende das mesmas premissas de aparelho, conta e faixa que foram testadas.
O filtro, o estabilizador e o navegador precisam de confirmações diferentes
A sessão de 5 de novembro envolveu um único participante, o autor, e dez pedidos para cinco alvos. Nove chegaram ao estado pronto, e o participante interrompeu o restante. Foi um experimento técnico e exploratório. Os pedidos tinham formulação livre, alguns repetiam objetivos e a configuração já conhecia os dispositivos. O total descreve o que aconteceu naquela sessão. A chance de um novo usuário conectar um aparelho desconhecido exige outra medição. Tabela e método do preprint
| Exemplo da sessão | O que o controle gerado produziu | Como confirmar que a ação funcionou |
|---|---|---|
| Filtro do OP-1 Field | O pedido de controles de filtro devolveu dois controles via MIDI | Uma mudança na saída do instrumento, gravada com entrada controlada ou ouvida por uma pessoa |
| DJI Osmo Mobile 4 | Um programa de mão e quatro controles chegaram ao estabilizador por uma ponte Bluetooth | Movimento observado ou posição verificada dentro dos limites de deslocamento previstos |
| Instagram Reels no Chrome | O pedido de gesto devolveu um programa de mão e três controles, usando teclas simuladas | A aba ou o item desejado muda e as outras janelas permanecem intactas |
A confirmação do transporte e a medição do efeito respondem a perguntas diferentes. Ilustração original do Telli.sh.
Pense no sintetizador. O MIDI pode transportar um comando de filtro válido enquanto o instrumento usa um timbre que responde de outra forma, ou está com a recepção MIDI desativada. O preprint descreve um caso anterior em que as mensagens recebiam confirmação, mas o instrumento ficou em silêncio até habilitarem a recepção. Uma mudança audível, registrada sobre uma nota de teste conhecida, diria mais do que uma segunda cópia do mesmo log.
O estabilizador mostra a mesma lição de outro jeito. A ponte registrou 889 respostas bem-sucedidas de rotação durante a sessão, inclusive comandos de parada e liberação. Isso demonstra que o transporte aceitou comandos em uma interação prolongada. Os logs não continham um ângulo confiável. Em um teste posterior, seria possível definir um alvo seguro e comparar o ângulo solicitado com um vídeo ou uma marca de referência. Aí daria para saber se o movimento foi preciso, repetível e limitado como pretendido.
O teclado traz um problema de identidade. Uma tecla pode ser pressionada com sucesso no sistema operacional e ainda chegar à janela errada. O teste no navegador deve conferir a aba ativa, confirmar a mudança no conteúdo esperado e verificar que as outras janelas ficaram intactas. Quanto mais abstrata for a interface do conector, mais importante fica definir o que significa terminar.
A parada precisa funcionar antes que alguém confie no gesto
A parada no ControlAnything independe do modelo. A pessoa pode interromper a geração, abrir as duas palmas durante o uso ou acionar um controle no menu do pulso. O sistema pode desativar o conector e emitir comandos neutros, como parar o estabilizador ou liberar o estado MIDI. A implementação usa um processo de trabalho restrito para o programa de mão no headset e verifica seu comportamento com 480 quadros sintéticos antes de liberá-lo. Também limita as ações declaradas e faixas de valores que o programa pode emitir. Segurança e interrupção no preprint
O conector do notebook tem outra posição. O preprint descreve um processo Node comum, executado com as permissões da pessoa que usa o notebook. O protótipo não isola esse processo gerado em um ambiente restrito. O SDK pode limitar os comandos enviados pelo caminho compatível, enquanto o conector capaz de executar código genérico mantém os poderes da conta em que roda. Uma versão confiável de produção restringiria esses privilégios no sistema operacional e permitiria acesso apenas aos aparelhos necessários ao pedido.
Imagine uma instalação com duas estruturas móveis. Uma interface que só identifica uma delas pode passar segurança. Ainda importa se o conector consegue descobrir a outra e agir sobre ela. Uma demonstração segura usa uma configuração em que o único alvo acessível é o que está em teste. Verifica a parada de forma independente, dá espaço para a pessoa se afastar e mostra o que acontece quando o rastreamento se perde ou o aparelho é desconectado.
A mesma distinção vale para código gerado que lê o ambiente. O protótipo instrui o modelo a tratar textos de quadros da câmera ou respostas de ferramentas como dados. A instrução orienta o comportamento. As permissões do processo e os caminhos de comunicação disponíveis determinam o alcance de um erro. São duas perguntas separadas antes de expor o notebook a aparelhos reais ou contas ativas.
Comece com um alvo simulado e limite o teste
O README do projeto descreve uma simulação para computador com Node 22.12 ou superior e Chrome. Segundo o projeto, sem chave de API o servidor repete respostas gravadas em um modo de teste claramente marcado. Assim é possível acompanhar a sequência entre marcar o alvo e receber controles antes de acrescentar headset, chamadas ao modelo ou aparelhos físicos. O limite do exercício também fica claro. Uma resposta gravada demonstra um caminho conhecido pela interface. A avaliação ao vivo começa quando você muda o alvo, o gesto ou a resposta do modelo. Instruções de demonstração do ControlAnything
- Leia as instruções do repositório e rode a simulação documentada em um ambiente descartável. Abra o simulador e o emulador de headset no computador e marque o notebook simulado que executa o sintetizador virtual.
- Escolha o pedido pronto de controles e confirme que o indicador de reprodução está visível. Observe como a interface representa o alvo selecionado e quando os controles gerados ficam disponíveis.
- Mude um botão virtual, confira o efeito no alvo simulado e teste a parada documentada. Separe o que observa na interface do que o conector registra.
- Para uma futura demonstração física, escolha um dispositivo de baixo risco com controle reversível. Registre o resultado esperado antes de enviar o comando. Tenha uma forma independente de ver ou ouvir a mudança e de parar o aparelho.
Em uma oficina, comece pelo sintetizador visual virtual, evitando um recurso que abre um serviço real ou pressiona teclas no computador anfitrião. O README distingue expressamente o caminho do Instagram Reels do exemplo simulado. Se você quer entender o mapeamento, um alvo local e limitado oferece um teste mais claro.
Ao passar para equipamento real, meça separadamente o tempo de configuração e a qualidade do controle. Cronometre até ficar pronto. Observe o atraso entre gesto e efeito, qualquer desvio quando a mão sai da área de rastreamento e o que acontece se a pessoa mudar de ideia. Um estudo mais longo pode responder a essas perguntas e verificar se alguém que nunca viu a interface escolhe o alvo certo sem ajuda.
Um controle útil pode ser criado e verificado
A melhor ideia do ControlAnything é permitir que a pessoa descreva uma interação física sem preparar antes uma interface sob medida. A avaliação mostra o processo com alvos conhecidos e um único headset. Um controle reutilizável precisa de mais do que uma conexão bem-sucedida. Deve identificar o aparelho, limitar o que pode fazer e tornar o efeito visível o suficiente para a pessoa confiar no que aconteceu.
Fontes
- Preprint do ControlAnything, submetido em 5 de novembro de 2026
- Implementação completa, avaliação e limitações
- Repositório, demonstrações e instruções do simulador
Para encontrar depois as anotações e decisões de uma sessão de prototipagem, crie uma conta no Telli.sh.