Ancres sous le millimètre et la question de la calligraphie

La plupart des expériences AR pardonnent quelques centimètres de dérive. Un tuteur de calligraphie ne pardonne rien. RakuAI est construit pour la précision où l'AR cesse d'être une démo et commence à être un enseignant.

Une conversation de partenariat était fraîche dans ma tête ce samedi matin, et une cible de précision avec elle qui m’a un peu fait peur. NTT QONOQ fait un travail sérieux d’AR culturelle au Japon, et le cas d’usage de calligraphie qu’ils veulent que ce moteur supporte a une spec sans pitié : le guide virtuel de trait d’encre qui se superpose à une feuille de papier d’entraînement doit atterrir exactement au même endroit sur exactement le même papier, chaque frame, chaque clignement.

La plupart des expériences AR sont indulgentes sur la précision. Si un robot virtuel se tient quelque part sur votre sol et qu’il dérive de trois centimètres quand vous détournez le regard et le reportez, vous ne le remarquerez peut-être pas. Le robot est un robot. Les robots errent.

Un tuteur de calligraphie n’est pas indulgent. Trois centimètres de dérive font un produit inutile. Trois millimètres de dérive font un produit frustrant. Le sous-millimètre est la barre. Ce week-end, le runtime a commencé à la franchir.

Ce qui a atterri

Cinq API et une référence de partenariat :

• API de pose d’ancrage sous-millimétrique pour l’alignement de contenu AR haute précision
• API de détection CV du papier pour l’étalonnage du papier basé sur des marqueurs
• Analyse CV du chemin de trait pour le suivi en temps réel du stylo et du pinceau
• Horodatages d’événements de latence vocale et métriques en temps réel
• Suivi de latence d’animation pour les démos orientées anime
• Une référence dans le README à la recherche avec NTT QONOQ

Soixante-dix commits sur le week-end. La majeure partie du travail d’ingénierie était dans les trois premiers.

Pourquoi « sous-millimétrique » est le bon chiffre

La demande de sous-millimètre n’est pas venue d’un exercice marketing. Elle est venue d’un cas d’usage. Un utilisateur tient un pinceau de calligraphie au-dessus d’une feuille de papier d’entraînement. Le runtime observe le pinceau, observe le papier, observe la pièce. Il superpose le prochain trait que l’utilisateur devrait faire comme une lueur discrète sur le papier. L’utilisateur suit la lueur.

Toute l’expérience s’effondre si la lueur est ne serait-ce que légèrement décalée du papier, parce que les yeux de l’utilisateur vont se fixer sur la lueur plutôt que sur la pointe physique du pinceau, et le trait physique va suivre la lueur mal alignée. La dérive dans la superposition produit une dérive dans le trait entraîné. Le produit disparaît.

Donc la barre n’est pas « le sous-millimètre est impressionnant ». La barre est « le sous-millimètre est le seul cas d’échec acceptable pour ce cas d’usage ». Au-dessus de ça, le produit casse.

Comment fonctionne l’ancre sous-millimétrique

Le mécanisme (simplifié) : le papier lui-même devient l’ancre. Un marqueur d’enregistrement imprimé sur le papier d’entraînement est détecté à chaque frame. Le runtime calcule la pose du papier relative à la vue de l’utilisateur en 6DoF. La superposition est rendue en coordonnées locales au papier, pas locales à la pièce. Quand la tête de l’utilisateur bouge, les mathématiques tournent dans l’autre sens : la pose du papier se met à jour, la superposition se re-projette, la lueur atterrit où va le prochain trait.

C’est une conception différente du standard « ancrer un objet virtuel à la pièce et faire confiance à la reconstruction de la pièce ». La reconstruction de pièce est bonne pour une précision à l’échelle du mobilier. Elle n’est pas bonne pour une précision à l’échelle du papier, parce que l’erreur de reconstruction de la pièce s’ajoute à l’erreur de pose de tête de l’utilisateur. En ancrant directement à un objet physique connu (le papier) et en enregistrant la superposition contre cet objet, nous effondrons la chaîne d’erreur.

Le coût est que le papier doit être un objet physique connu. Nous avons résolu cela ce week-end avec l’API de détection CV du papier basée sur des marqueurs. Le marqueur est petit, discret, et imprimé sur chaque feuille d’entraînement avec laquelle la démo est livrée. Le runtime détecte le marqueur en environ deux millisecondes par frame et le suit de façon stable dans un éclairage typique.

Le gain est que nous faisons cela sur des lunettes AR avec l’enveloppe de calcul qu’elles ont, en temps réel, à chaque frame, avec une dérive de superposition bornée sous le millimètre dans un usage normal.

La référence NTT QONOQ

J’ai ajouté une référence à NTT QONOQ dans le README ce week-end parce que nous sommes en conversation de recherche active. NTT QONOQ au Japon fait un travail sérieux sur l’AR du monde réel et sur la question de comment les expériences AR s’ancrent à des artefacts physiques. Le cas d’usage de la calligraphie s’aligne avec le type de travail d’AR culturelle que la communauté japonaise de l’informatique spatiale fait avancer.

Ce n’est pas une annonce de partenariat. C’est une note que la conversation de partenariat a lieu et que l’ingénierie de ce week-end reflète ce qui serait nécessaire pour bien la supporter. La question produit « pouvez-vous faire ça dans une salle de classe de calligraphie à Tokyo » est plus concrète que la question produit « pouvez-vous faire ça quelque part ». Les questions concrètes produisent une meilleure ingénierie.

Le CV du chemin de trait : la partie la plus difficile

L’ancre sous-millimétrique est la vedette de ce week-end. La véritable pièce d’ingénierie la plus difficile était le CV du chemin de trait.

Suivre un stylo ou un pinceau en temps réel sur des lunettes AR n’est pas un problème résolu. La pointe est petite, souvent partiellement occluse par la main de l’utilisateur, et se déplace à vitesse variable. Le pipeline CV de ce week-end suit la position de la pointe relative au papier, infère quand la pointe est en contact (par opposition à en survol), et émet un chemin de trait comme un flux de points horodatés. La récupération d’occlusion de main est la partie qui a mangé le plus de temps. L’agent et moi avons parcouru trois versions de la logique de récupération avant que les traces de test n’arrêtent de perdre des points.

C’est le genre d’ingénierie où l’IA en tant que primitive de runtime commence à compter. Le pipeline CV reçoit chaque frame. Un petit modèle sur l’appareil décide si la frame actuelle est une frame de contact ou une frame de survol. La décision du modèle alimente l’émetteur de chemin de trait. Le modèle n’est pas un chatbot. C’est un élément de runtime qui tourne à l’étape de simulation.

Ce schéma architectural devient un refrain dans ce moteur. L’IA n’est pas la fonctionnalité qu’on ajoute. L’IA est ce qui se passe entre les capteurs et le moteur de rendu, à chaque frame, pendant que l’utilisateur fait ce qu’il fait.

Ce que je veux que les partenaires et bâtisseurs retiennent de ceci

Si vous êtes NTT QONOQ ou tout autre partenaire réfléchissant aux superpositions AR de précision dans des environnements réels, le travail de tuteur de calligraphie est une démo concrète du type de précision que cible le moteur. Le cadre est général. Ce n’est pas spécifiquement un outil de calligraphie. C’est une ancre sous-millimétrique et un pipeline CV de chemin de trait, tous deux applicables à beaucoup de choses qui ne ressemblent en rien à la calligraphie.

Si vous êtes un laboratoire IA avec un petit modèle qui excelle dans la segmentation de main ou de stylo, c’est le type de modèle qui vit à l’intérieur de l’étape de simulation sur ce moteur. Le budget de latence est serré. La barre de qualité est haute. Si votre modèle rentre, ce moteur a un emplacement pour lui.

Soixante-dix commits. Une cible de démo. Une conversation de partenariat qui s’accélère. Le genre de samedi que je n’échangerais contre rien.