RynnBrain 1.1 : le test d'acceptation de la manipulation de robots 3D pour les opérateurs

Un robot peut identifier le bon objet tout en ratant le travail. La tasse est visible. Le modèle le souligne. Ensuite, la pince s'approche à partir du mauvais cadre de coordonnées, attrape la paroi incurvée au lieu de la région de la poignée, clipse l'élément à côté et transforme une victoire de perception en un échec de manipulation. C’est dans cet écart, entre voir et agir en toute sécurité, que devrait se situer un test d’acceptation RynnBrain 1.1.

Alibaba DAMO Academy présente RynnBrain 1.1 comme une famille de modèles de fondation incarnés ouverts aux échelles 2B, 9B et 122B-A10B. La page et l'article du projet décrivent la mise à la terre 3D native pour les modèles compacts, la prédiction du point de contact avec une orientation de préhension dans le plan et RynnBrain-VLA avec un espace d'action inter-incarnations unifié ainsi qu'un masquage spécifique à l'incarnation. Les mêmes documents font également état d'évaluations de robots réels sur les systèmes Unitree G1, Astribot-S1 et Tianji-Wuji. Traitez ces résultats de référence et de robot réel comme des affirmations rapportées par l'auteur jusqu'à ce que votre équipe les reproduise.

Pour les opérateurs, la version est intéressante. Ce n’est pas la question difficile. La question difficile est de savoir si cela transmettra vos artefacts, vos robots, vos scènes, votre processus de sécurité, votre budget de latence et votre chemin de récupération. Si votre équipe compare des piles robotiques ouvertes associées, associez cet article à la planification de l'infrastructure robotique de pointe d'Optijara, acceptation de la récupération de modèle ouvert testing, et production servant l'évaluation.

Pourquoi RynnBrain 1.1 a besoin d'un test d'acceptation

RynnBrain 1.1 n'est pas une carte modèle pour survoler un café. Ses revendications se situent à la frontière entre la perception, le raisonnement spatial, le contrôle des robots et le contact physique. La page officielle indique que RynnBrain 1.1 introduit la prédiction des points de contact pour les emplacements d'interaction pertinents pour la tâche et les orientations de préhension dans le plan, tandis que les modèles 2B et 9B reçoivent une supervision 3D explicite pour un ancrage conditionné par le langage dans un espace physique métrique. L'article arXiv doit être traité comme la principale référence technique, GitHub, Hugging Face et ModelScope étant utilisés pour confirmer les artefacts exécutables.

Voici la version brutale : un tableau de référence n’est pas une limite de contrôle. Il vous indique par où commencer les tests. Il ne vous dit pas quoi automatiser.

Gardez les réclamations séparées. Les tableaux de référence, les comparaisons de mise à l'échelle et les déclarations de supériorité de robots réels sont rapportés par l'auteur jusqu'à ce que votre équipe les reproduise sous le code épinglé, les points de contrôle épinglés, le matériel documenté et la distribution de votre scène cible. Cela ne rend pas les affirmations faibles. Cela les rend testables. L’adoption de la robotique tourne mal lorsque les équipes confondent un résultat papier avec une décision de production.

Le test d'acceptation de manipulation Optijara 3D est conçu pour ce problème. Il sépare la perception 2D de la mise à la terre métrique 3D, la mise à la terre métrique du contact utilisable, le contact de l'exécution spécifique au robot et l'exécution du déploiement sécurisé. La règle est simple : si une version ne peut pas passer une version contrainte du workflow réel, elle doit rester en évaluation.

Que vérifier en premier : artefacts, licences et adéquation au modèleAvant tout essai de robot, créez un dossier d'adoption. Capturez l'URL officielle du projet, le document arXiv, le référentiel GitHub, la collection Hugging Face, la collection ModelScope, les noms de points de contrôle, les cartes de modèle, le texte de licence, les versions de dépendances, les exemples de commandes d'inférence et toute déclaration de sécurité ou de limitation. Le référentiel GitHub annonce une licence Apache-2.0 dans l'instantané du référentiel en direct vérifié lors de la vérification des faits, mais les opérateurs doivent toujours confirmer si chaque artefact de modèle, dépendance d'ensemble de données et intégration en aval correspond aux conditions de redistribution et d'utilisation commerciale.

Ne téléchargez pas de point de contrôle et appelez l'artefact vérifié. Enregistrez les identifiants de validation, les horodatages de publication le cas échéant, les fichiers de hachage s'ils sont publiés, vos propres hachages de fichiers téléchargés, les fichiers de verrouillage d'environnement, les versions de pilotes GPU, les scripts d'inférence et les lignes de commande d'évaluation. Six mois plus tard, c'est cette piste de preuves qui vous indique si un benchmark a dérivé en raison du modèle, du matériel, du prétraitement ou de votre configuration.

Matrice de décision 2B vs 9B vs 122B-A10B

Pour les plates-formes robotisées, évaluez la plate-forme avant d'évaluer le modèle. Unitree G1, Astribot-S1 et Tianji-Wuji sont nommés dans l'article et les documents du projet RynnBrain. Ils représentent différentes hypothèses de réalisation : mobilité et manipulation humanoïde, manipulation bimanuelle et contrôle manuel adroit. Documentez la suite de capteurs, la géométrie de l'effecteur final, la taxonomie de compréhension, l'API de contrôle, la procédure d'étalonnage, les limites de l'espace de travail, le modèle de collision, le mécanisme d'arrêt de sécurité et les données de démonstration disponibles pour chaque plate-forme.

Le test d'acceptation de manipulation 3D Optijara

Le cadre a sept portes. L'intégrité des artefacts vient en premier, suivie par la reproduction hors ligne, la mise à la terre métrique 3D, la viabilité des contacts, la cartographie des incarnations, l'examen de l'enveloppe de sécurité et le déploiement supervisé limité. Une figurine ne passe que lorsque chaque porte possède des preuves. Les impressions ne comptent pas.

Étape 1 : localisation 2D versus mise à la terre métrique 3D

Le pointage 2D demande si le modèle peut indiquer une cible dans l'espace image. La manipulation demande si le robot peut atteindre le bon endroit dans le monde réel. Votre test doit comparer les cadres de délimitation ou les points avec des cibles 3D métriques, la cohérence de la profondeur, l'orientation des objets, les surfaces accessibles et les transformations entre la caméra, le monde, la base du robot et les cadres d'outils.Commencez avec un décor de scène fixe. Incluez les objets connus, les objets nouveaux, les surfaces encombrées, les cibles occluses et les objets transparents ou réfléchissants s'ils apparaissent dans le flux de travail. Ajoutez également des changements d'état : ouvert ou fermé, droit ou incliné, vide ou rempli. Une réponse 3D valide doit se répéter après le recalibrage et résister à un éclairage modéré ou à des changements de point de vue.

Étape 2 : Notation du point de contact et de l'orientation de saisie

La prédiction des points de contact n’est utile que si elle survit à la physique. Vérifiez si le point prédit se trouve à l'intérieur d'une région de contact valide pour la tâche, si le vecteur d'approche dégage les objets à proximité, si l'orientation de la pince correspond à la géométrie de l'objet et si le contact proposé évite les risques de glissement, de couple ou de collision que vos capteurs peuvent observer.

Étape 3 : Calibrage et cohérence du référentiel

De nombreux échecs de manipulation ne sont pas des échecs de modèle. Il s'agit de bugs de frame, de dérives d'horodatage, d'erreurs d'échelle de profondeur, d'extrinsèques obsolètes ou de transformations d'outils qui ne correspondent plus au matériel. Auditez les éléments extrinsèques de la caméra, le cadre de base du robot, la transformation de l'effecteur final, l'échelle de profondeur, l'alignement de l'horodatage, l'étalonnage œil-main et la répétabilité du réétalonnage. Exiger que la sortie du modèle soit enregistrée avec le cadre auquel elle fait référence. Un point sans cadre n’est pas un plan d’action.

Étape 4 : Encombrement, occlusion et changements d'état des objets

Des démonstrations de table claire sont nécessaires, mais elles ne prouvent pas grand-chose en elles-mêmes. Ajoutez des distractions, des occlusions partielles, des changements d'état du conteneur, des emballages déformables, des surfaces réfléchissantes et des mouvements d'objets entre la perception et l'exécution. Le test d'acceptation doit enregistrer si les échecs proviennent de la perception, de l'ancrage, de la prédiction de contact, de la planification, du contrôle ou de la récupération.

Évaluation VLA inter-incarnations : du plan de tâche à l'action sûre

Un VLA à modes de réalisation croisés doit être testé en tant que chaîne. La compréhension des instructions mène à la planification des sous-tâches. La planification mène à l’ancrage de la scène. L’ancrage mène à des propositions d’action. Les propositions d'action sont traduites en commandes spécifiques au robot. Le robot exécute, observe le résultat et continue ou récupère. Un maillon faible n’importe où dans cette chaîne peut invalider le déploiement.

Les tâches à long horizon doivent varier l'emplacement des objets, les distractions, l'éclairage, les états intermédiaires et la formulation des instructions. La décomposition doit rester stable lorsque la scène change, mais elle ne peut pas être rigide. Si une tasse tombe, le système ne doit pas continuer aveuglément la prise initiale.

La cartographie inter-incarnations est la partie la plus difficile à simuler. Les actions abstraites telles que prélever, verser, pousser, essuyer, placer ou remettre doivent correspondre à l'espace de travail accessible de chaque plate-forme robotique, à la géométrie de la pince ou de la main, aux limites des articulations, aux cadres d'outils, au modèle de collision et à l'enveloppe de force ou de vitesse. Les masques spécifiques à un mode de réalisation doivent bloquer les poses inaccessibles, les orientations dangereuses, les zones interdites, les forces excessives et les actions incompatibles avec les outils.L'observabilité est obligatoire. Invite de journal, images, entrées de profondeur, point de contact prévu, cadre de coordonnées cible, trace d'action, décisions de masque, confiance ou incertitude en cas d'exposition, branche de récupération, remplacement de l'opérateur et étiquette de résultat final. Sans cette trace, vous ne pouvez pas distinguer une faiblesse du modèle d'un problème d'étalonnage ou d'un bug du contrôleur.

Plan de reproduction et de mesure du benchmark

Les matériaux RynnBrain font référence à la cognition incarnée, au raisonnement spatial, à la localisation, à la mise à la terre 3D et à l'évaluation d'un robot réel. L'ensemble de reproduction requis doit inclure les scripts d'évaluation officiels de RynnBrain lorsqu'ils sont disponibles et la documentation de référence pertinente telle que VSI-Bench, MMSI-Bench, RefSpatial-Bench et la page de l'ensemble de données RynnBrain-Bench. Traitez chaque référence comme un instrument de mesure et non comme un proxy de déploiement. Un modèle peut réussir en matière de compréhension spatiale tout en faisant échouer votre pince, votre ensemble d'objets, votre budget de latence ou votre enveloppe de sécurité.

La reproduction doit inclure le code PIN, le point de contrôle, la version de l'ensemble de données, le matériel, la pile de pilotes, les graines aléatoires le cas échéant, le prétraitement de l'image, les modèles d'invite et les scripts d'évaluation. Si l'article rapporte un résultat de référence, reproduisez-le avant de l'utiliser dans une note d'adoption. Si la reproduction échoue, enregistrez le bloqueur : artefacts manquants, incompatibilité d'environnement, prétraitement non documenté, différence matérielle ou erreur d'implémentation.

Simulez d’abord, puis utilisez des essais physiques contraints. Les tests de robots réels doivent s'exécuter à faible vitesse, dans un espace de travail délimité, avec un accès pour arrêt d'urgence, un fonctionnement supervisé et des conditions d'abandon définies. Les ressources robotiques de fabrication intelligente du NIST sont utiles pour la réflexion sur l'évaluation, mais ne considèrent pas un test d'acceptation de recherche comme une certification de sécurité.

{
  "model": "RynnBrain 1.1",
  "acceptance_gates": ["artifact_integrity", "benchmark_reproduction", "metric_3d_grounding", "contact_viability", "embodiment_mapping", "safety_envelope", "supervised_trial"],
  "required_metrics": ["valid_3d_target_rate", "contact_point_validity", "grasp_orientation_validity", "intervention_rate", "recovery_success", "latency_distribution", "calibration_drift_sensitivity"],
  "deployment_blockers": ["unverified_license", "unreproduced_benchmark", "missing_frame_trace", "unsafe_action_mask_gap", "uncontained_failure"],
  "first_trial_scope": "single robot, bounded workspace, known objects plus controlled clutter, supervised low-speed execution"
}

Erreurs courantes, mises en garde et endroits où ne pas déployer

Les équipes se trompent de manière prévisible. Ils considèrent le pointage 2D comme une preuve de préparation à la manipulation 3D. Ils ignorent les audits d'étalonnage parce qu'une démonstration a fonctionné une fois. Ils font confiance à des références papier sans reproduction. Ils ignorent les différences de mode de réalisation. Ils testent uniquement des scènes propres. Ils omettent la reprise après incident. Ils mesurent la réussite des tâches mais négligent la qualité des contacts, les quasi-accidents, les interventions et les erreurs de cadre.

Les mises en garde opérationnelles sont importantes. L’évaluation prend du temps d’ingénierie. Le comportement du modèle peut varier en fonction de la taille, du chemin de desserte, de la qualité du capteur, du format d'invite et du contrôleur du robot. Les flux de caméra peuvent contenir des informations sensibles. La simulation peut masquer les frictions, la conformité, la latence et les changements d’état des objets. Dérives d’étalonnage. Le matériel s'use. L'inférence en réseau peut ajouter de la gigue. Certains artefacts du modèle peuvent exposer moins d’incertitudes ou de détails de trace que ce que souhaitent les opérateurs.

Ne déployez pas de modèle incarné ouvert dans des manipulations non supervisées critiques pour la sécurité, des espaces publics illimités, des interactions à forte force, des tâches nécessitant un comportement de sécurité certifié, des outils instables ou des flux de travail dans lesquels les pannes ne peuvent pas être contenues. Évitez les déploiements qui capturent des données visuelles sensibles sans gouvernance, ou dans lesquels les opérateurs ne peuvent pas inspecter et ignorer les actions.

Le chemin pratique est étroit et précieux : vérifiez la version, reproduisez ce que vous pouvez, exécutez un test d'acceptation de manipulation 3D contenue et définissez des critères de rejet avant le déploiement. Pour les équipes évaluant l'IA incarnée ouverte, Optijara peut aider à traduire des versions telles que RynnBrain 1.1 en plans de test, en portes de prototypes, en reproduction de référence et en feuilles de route d'automatisation plus sûres sans surestimer l'état de préparation.