AI Tools11 min de leitura

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.

K
Ken Jo

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.

Controles gerados para um sintetizador OP-1 Field na gravação do headset do ControlAnything

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

Quatro etapas separam a escolha do alvo, a geração do conector, o envio do comando e a observação do efeito

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ãoO que o controle gerado produziuComo confirmar que a ação funcionou
Filtro do OP-1 FieldO pedido de controles de filtro devolveu dois controles via MIDIUma mudança na saída do instrumento, gravada com entrada controlada ou ouvida por uma pessoa
DJI Osmo Mobile 4Um programa de mão e quatro controles chegaram ao estabilizador por uma ponte BluetoothMovimento observado ou posição verificada dentro dos limites de deslocamento previstos
Instagram Reels no ChromeO pedido de gesto devolveu um programa de mão e três controles, usando teclas simuladasA aba ou o item desejado muda e as outras janelas permanecem intactas

O sistema pode registrar um comando aceito enquanto a resposta física depende de observação separada

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

  1. 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.
  2. 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.
  3. 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.
  4. 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


Para encontrar depois as anotações e decisões de uma sessão de prototipagem, crie uma conta no Telli.sh.


← Voltar ao blog