Âncoras Sub-Milimétricas e a Questão da Caligrafia

A maioria das RAs perdoa alguns centímetros de desvio. Um tutor de caligrafia não perdoa nada. A RakuAI é construída para a precisão em que a RA para de ser uma demo e começa a ser uma professora.

Uma conversa de parceria estava fresca na minha cabeça neste sábado de manhã, e um alvo de precisão junto com ela que me assustou um pouco. A NTT QONOQ vem fazendo um trabalho sério de RA cultural no Japão, e o caso de uso de caligrafia que eles querem que este motor suporte tem uma especificação implacável: o guia virtual de traço de tinta que se sobrepõe a uma folha de papel de prática precisa cair exatamente no mesmo ponto do mesmo papel, a cada frame, a cada piscar de olhos.

A maioria das experiências de RA é tolerante quanto à precisão. Se um robô virtual está de pé em algum lugar do seu chão e ele desvia três centímetros quando você olha para outro lado e volta a olhar, você pode nem notar. O robô é um robô. Robôs vagueiam.

Um tutor de caligrafia não é tolerante. Três centímetros de desvio é um produto inútil. Três milímetros de desvio é um produto frustrante. Sub-milimétrico é a régua. Neste fim de semana o runtime começou a superá-la.

O que entrou

Cinco APIs e uma referência de parceria:

• API de pose de âncora sub-milimétrica para alinhamento de conteúdo de RA de alta precisão
• API de detecção de papel por CV para calibração de papel baseada em marcador
• Análise de CV de caminho de traço para rastreamento de caneta e pincel em tempo real
• Timestamps de eventos de latência de voz e métricas em tempo real
• Rastreamento de latência de animação para demos voltadas a anime
• Uma referência no README a pesquisa com a NTT QONOQ

Setenta commits ao longo do fim de semana. A maior parte do trabalho de engenharia estava nos três primeiros.

Por que “sub-milimétrico” é o número certo

O pedido de sub-milímetro não veio de um exercício de marketing. Veio de um caso de uso. Um usuário segura um pincel de caligrafia sobre uma folha de papel de prática. O runtime observa o pincel, observa o papel, observa o cômodo. Ele sobrepõe o próximo traço que o usuário deve fazer como um brilho tênue no papel. O usuário segue o brilho.

A experiência inteira desmorona se o brilho estiver mesmo que ligeiramente fora do papel, porque os olhos do usuário vão se fixar no brilho em vez de na ponta física do pincel, e o traço físico vai seguir o brilho desalinhado. Desvio no overlay produz desvio no traço praticado. O produto desaparece.

Então a régua não é “sub-milimétrico é impressionante.” A régua é “sub-milimétrico é o único caso de falha aceitável para este caso de uso.” Acima disso o produto quebra.

Como a âncora sub-milimétrica funciona

O mecanismo (simplificado): o próprio papel se torna a âncora. Um marcador de registro impresso no papel de prática é detectado a cada frame. O runtime computa a pose do papel em relação à visão do usuário em 6DoF. O overlay é renderizado em coordenadas locais ao papel, não locais ao cômodo. Conforme a cabeça do usuário se move, a matemática roda na direção contrária: a pose do papel se atualiza, o overlay se reprojeta, o brilho cai onde o próximo traço vai.

Este é um design diferente do padrão “ancorar um objeto virtual ao cômodo e confiar na reconstrução do cômodo.” A reconstrução do cômodo é boa para precisão em escala de móveis. Não é boa para precisão em escala de papel, porque o erro da reconstrução do cômodo se acumula com o erro de pose da cabeça do usuário. Ao ancorar diretamente em um objeto físico conhecido (o papel) e registrar o overlay contra esse objeto, colapsamos a cadeia de erro.

O custo é que o papel precisa ser um objeto físico conhecido. Resolvemos isso neste fim de semana com a API de detecção de papel por CV baseada em marcador. O marcador é pequeno, discreto, e impresso em toda folha de prática com que a demo é lançada. O runtime detecta o marcador em aproximadamente dois milissegundos por frame e o rastreia de forma estável sob iluminação típica.

O ganho é que estamos fazendo isso em óculos de RA com o envelope de computação que eles têm, em tempo real, a cada frame, com desvio de overlay limitado abaixo de um milímetro em uso normal.

A referência à NTT QONOQ

Adicionei uma referência à NTT QONOQ no README neste fim de semana porque estamos em uma conversa de pesquisa ativa. A NTT QONOQ no Japão vem fazendo um trabalho sério sobre RA no mundo real e sobre a questão de como experiências de RA se ancoram a artefatos físicos. O caso de uso de caligrafia se alinha com o tipo de trabalho de RA cultural que a comunidade japonesa de computação espacial vem empurrando para frente.

Isto não é um anúncio de parceria. É uma nota de que a conversa de parceria está acontecendo e a engenharia deste fim de semana reflete o que seria necessário para apoiá-la bem. A pergunta de produto “você consegue fazer isso em uma sala de aula de caligrafia em Tóquio” é mais concreta do que a pergunta de produto “você consegue fazer isso em algum lugar.” Perguntas concretas produzem engenharia melhor.

CV de caminho de traço: a mais difícil

A âncora sub-milimétrica é a estrela deste fim de semana. A peça de engenharia de fato mais difícil foi a CV de caminho de traço.

Rastrear uma caneta ou pincel em tempo real em óculos de RA não é um problema resolvido. A ponta é pequena, frequentemente parcialmente ocluída pela mão do usuário, e se movendo em velocidade variável. O pipeline de CV deste fim de semana rastreia a posição da ponta em relação ao papel, infere quando a ponta está em contato (versus pairando), e emite um caminho de traço como um fluxo de pontos com timestamp. A recuperação de oclusão de mão foi a parte que consumiu mais tempo. Eu e o agente passamos por três versões da lógica de recuperação antes de os traces de teste pararem de perder pontos.

Este é o tipo de engenharia em que a IA como primitiva de runtime começa a importar. O pipeline de CV recebe cada frame. Um modelo pequeno no dispositivo decide se o frame atual é um frame de contato ou um frame de pairar. A decisão do modelo alimenta o emissor de caminho de traço. O modelo não é um chatbot. É um elemento de runtime que roda na etapa de simulação.

Esse padrão arquitetural está virando um refrão neste motor. IA não é a funcionalidade que você adiciona. IA é a coisa que acontece entre sensores e renderizador, a cada frame, enquanto o usuário está fazendo o que quer que esteja fazendo.

O que eu quero que parceiros e construtores tirem disso

Se você é a NTT QONOQ ou qualquer outro parceiro pensando em overlays de RA de precisão em ambientes reais, o trabalho do tutor de caligrafia é uma demo concreta do tipo de precisão que o motor tem como alvo. O framework é geral. Não é especificamente uma ferramenta de caligrafia. É uma âncora sub-milimétrica e um pipeline de CV de caminho de traço, ambos aplicáveis a muitas coisas que não se parecem nada com caligrafia.

Se você é um lab de IA com um modelo pequeno que se sai bem em segmentação de mão ou caneta, este é o tipo de modelo que vive dentro da etapa de simulação neste motor. O orçamento de latência é apertado. A régua de qualidade é alta. Se o seu modelo cabe, este motor tem um espaço para ele.

Setenta commits. Um alvo de demo. Uma conversa de parceria acelerando. O tipo de sábado que eu não trocaria por nada.