Test d'acceptation de route de politique Xiaomi-Robotics-1 : faire passer les checkpoints VLA vers un deploiement securise

Un checkpoint robotique peut sembler solide dans un benchmark et rester non pret pour une cellule de travail calibree. Le vrai test d'acceptation de route de politique Xiaomi-Robotics-1 commence dans les moments difficiles : la camera bouge, un objet arrive hors de la pose attendue, la reinitialisation echoue, la latence d'inference augmente brusquement, ou un operateur a besoin que le systeme s'arrete avant qu'une petite erreur ne devienne un incident de securite.

C'est le bon angle pour Xiaomi-Robotics-1. Le projet officiel le decrit comme un modele fondation robotique vision-langage-action entraine avec plus de 100 000 heures de trajectoires de manipulation UMI en conditions reelles, puis suivi d'un post-entrainement sur plus de 10 000 heures de donnees multi-incarnations. Le depot, la page projet, le rapport arXiv, la collection Hugging Face, le code de deploiement et les dossiers d'evaluation de benchmark le rendent plus utile qu'une publication limitee a une demonstration. Ils elargissent aussi la surface d'evaluation.

La question utile n'est pas de savoir si ce checkpoint equivaut a l'autonomie robotique. Elle est de savoir si ce checkpoint peut devenir une route candidate : un chemin de politique borne qui peut etre reproduit, epingle, observe en shadow mode, deploye en canary, desactive et ramene en arriere. Un benchmark demande si un modele peut terminer des taches dans une configuration definie. Un test d'acceptation de route demande si une equipe peut reproduire l'artefact, l'associer a l'incarnation de son robot, mesurer toute la boucle perception-politique-action, et maintenir l'autorite humaine intacte lorsque le comportement devient etrange.

Cet angle differe des travaux de robotique video en edge, ou la surface de decision principale porte sur le debit des capteurs, les codecs et les pipelines video sur appareil. Pour un contexte plus large sur l'infrastructure robotique, voir l'article connexe d'Optijara sur JetPack 7.2.1 et la robotique video en edge. Xiaomi-Robotics-1 pose une question separee : un checkpoint de politique VLA ouvert peut-il devenir une route de politique robotique contenue apres des points de controle sur la calibration, le timing, la securite et la recuperation ? Pour des modeles adjacents d'evaluation de politiques robotiques ouvertes, comparez avec le test d'acceptation corps entier LingBot-VLA 2.0 d'Optijara.

Pourquoi Xiaomi-Robotics-1 a besoin d'une porte de deploiement, pas d'un autre recapitulatif de benchmark

Le README officiel indique que Xiaomi-Robotics-1 couple un VLM preentraine, Qwen3-VL, avec un Diffusion-Transformer au moyen d'une conception Mixture-of-Transformers. Il rapporte plus de 100 000 heures de trajectoires UMI sans incarnation couvrant plus de 1 700 scenarios, puis un post-entrainement avec des donnees multi-incarnations, incluant des donnees internes de robots reels, des donnees robotiques open source filtrees et des donnees UMI annotees manuellement. La collection Hugging Face liste les checkpoints publies, dont Xiaomi-Robotics-1-5B et des checkpoints propres aux benchmarks RoboCasa, RoboCasa365 et VLABench.

Ces artefacts meritent l'attention. Ils ne constituent pas une preuve de deploiement. Le README rapporte des scores de benchmark sur RoboCasa, RoboCasa365, VLABench et RoboDojo, dont 57,4 pour cent sur RoboCasa365 contre 46,6 pour cent pour la deuxieme meilleure entree du tableau. Traitez ces chiffres comme des affirmations de benchmark rapportees par le projet jusqu'a ce qu'une equipe les reproduise avec du code epingle, des poids epingles, des versions de simulateur correspondantes et des parametres d'evaluation correspondants.

Le probleme de deploiement est plus desordonne que l'achevement de taches dans un benchmark. Une route robotique doit resister a la derive de calibration, aux images obsoletes, aux occlusions partielles, aux deplacements d'objets, aux erreurs de reinitialisation, aux frontieres reseau, aux bogues d'adaptateur d'action et a l'intervention humaine. Si la politique passe par une separation client-serveur, comme le decrivent les guides d'evaluation RoboCasa et VLABench, le test d'acceptation doit aussi mesurer les allers-retours socket, le surcout de serialisation, l'inference du modele, l'envoi des actions, la reponse des actionneurs et la gigue sur des boucles repetees. La meme discipline de preparation s'applique aussi hors de la robotique, comme le montre le test d'acceptation Cloudflare Agent Readiness AEO d'Optijara.

La carte des artefacts : ce que les equipes doivent epingler avant tout mouvement du robot

Avant qu'un robot bouge, l'equipe a besoin d'une carte des artefacts qui puisse etre reconstruite plus tard. Epinglez le commit du depot public, la revision exacte du checkpoint Hugging Face, les hachages de fichiers des artefacts de modele, la licence de code Apache-2.0, les termes de la model card, le lockfile des dependances, la pile CUDA et PyTorch, les versions de transformers, les versions de simulateur, les configs de benchmark, les scripts de deploiement, et tout firmware robotique ou build de controleur utilise dans les tests materiels.

Le code du serveur de deploiement charge un AutoModel avec trust_remote_code, flash attention, bfloat16, CUDA, et renvoie des tenseurs d'action pickles. Le README d'evaluation RoboCasa specifie RoboCasa v0.2, Python 3.10, transformers 4.57.1, et une separation client-serveur entre deux environnements conda. Le README d'evaluation VLABench specifie son propre environnement, des versions epinglees de MuJoCo et dm_control, ainsi qu'une forme d'action brute de [10, 60], avec les 7 premieres dimensions executables pour le delta de position, le delta de rotation d'Euler et le controle de pince.

Le contrat d'entree/sortie a besoin de son propre inventaire. Enregistrez les noms des cameras, la resolution d'image, le pretraitement, le format d'instruction, les champs de proprioception s'ils sont utilises, le task_id ou la cle robot, la forme du tenseur d'action, la mise a l'echelle des actions, la semantique de pince, la frequence d'action, le comportement de batch, le protocole d'endpoint et la couche d'adaptateur propre au robot. Si un champ reste implicite, l'equipe n'evalue pas une route. Elle parie. Pour les equipes qui formalisent des portes plus larges de publication de modeles, le test d'acceptation de deploiement Motif 3 d'Optijara offre un parallele utile pour separer les affirmations de modele des preuves de route.

Le cadre R-PATH d'Optijara pour l'acceptation de routes de politiques robotiques

R-PATH est un cadre pratique d'acceptation pour passer d'un checkpoint de recherche a une route de politique robotique contenue. Il signifie Reproduce, Pin, Align, Test, and Hold.

R : reproduire la route publiee

Commencez en simulation, pas sur materiel. Reproduisez le chemin documente RoboCasa, RoboCasa365 ou VLABench qui correspond au checkpoint que vous prevoyez d'inspecter. Les documents d'evaluation Xiaomi-Robotics-1 utilisent une configuration client-serveur ou le serveur charge le modele et sert les actions via une socket, tandis que le client execute le simulateur, construit les entrees avec AutoProcessor et decode les actions. Cette frontiere est l'endroit ou beaucoup de problemes de deploiement apparaissent.

P : epingler la politique et la plateforme

Une fois qu'une execution de reference existe, gelez tout ce qui est mutable. Epinglez le code, le checkpoint, les dependances, le comportement du processeur, les assets du simulateur, les definitions de taches, les scripts de lancement, les variables d'environnement et la configuration materielle. Ajoutez des checksums pour les fichiers de modele et les fichiers d'adaptateur de route. Stockez les commandes de lancement a cote des metadonnees d'execution.

A : aligner les cameras, les actions et l'incarnation

Le preentrainement sans incarnation est prometteur parce qu'il peut apprendre de larges motifs de manipulation avant l'alignement propre au robot. Il ne supprime pas le besoin d'un mapping propre au robot. Alignez les intrinseques et extrinseques des cameras, les conventions de reperes, l'eclairage, le recadrage d'image, l'echelle des objets, les limites de l'espace de travail, la pose de base, la cinematique du bras, la mise a l'echelle des actions, la semantique d'ouverture et de fermeture de la pince, les positions de reinitialisation et les definitions de taches.

T : tester le timing en boucle fermee et la recuperation

Mesurez toute la boucle, pas seulement l'inference du modele. La boucle inclut la capture camera, le pretraitement, le transfert reseau s'il est utilise, l'inference du modele, la serialisation des actions, la conversion par l'adaptateur d'action, l'envoi au controleur, la reponse des actionneurs, la mise a jour de l'observation et l'evaluation de la porte de securite. Enregistrez les distributions de latence et la gigue, pas seulement les moyennes. Puis testez les occlusions, les images retardees, les observations obsoletes, les instructions ambigues, les objets deplaces, les prises ratees, les chemins bloques, les echecs de reinitialisation et les evenements d'arret d'urgence.

H : maintenir l'autorite humaine et le rollback

Aucune route VLA ne doit depasser le mecanisme d'arret. L'autorite humaine d'arret, les limites physiques de l'espace de travail, le repli en arret securise, le repli vers un controleur de reference, le shadow mode, le mode canary et les regles de rollback doivent exister avant l'expansion.

Matrice de decision de route : quand Xiaomi-Robotics-1 est pret, non pret ou seulement pret pour sandbox

Cette matrice est volontairement conservatrice. Une reussite de benchmark peut justifier la poursuite de l'evaluation. Elle ne doit pas autoriser a elle seule l'actionnement dans une cellule de travail de production. Xiaomi-Robotics-1 peut etre le bon candidat pour une evaluation large de manipulation, mais un controleur script plus etroit, une politique d'apprentissage par imitation, un workflow assiste par teleoperation ou une pile robotique propre a un fournisseur peut etre meilleur pour une tache contrainte avec des exigences strictes de repetabilite. C'est de l'ingenierie ordinaire : utilisez le modele quand l'adaptabilite compte, et utilisez un controle plus simple quand la repetabilite compte davantage.

Checklist d'implementation : du checkpoint a la route robotique calibree

Commencez avec des predictions shadow, ou la politique observe mais n'actionne pas. Comparez les actions proposees aux enveloppes securisees attendues. Passez ensuite a des taches canary contenues avec supervision humaine, limites physiques et repli de reference. Si un canary echoue a cause de la calibration, de la latence, de la reinitialisation ou d'un comportement hors distribution, ramenez la route en arriere plutot que de modifier l'environnement jusqu'a ce que l'echec disparaisse.

Ce que les equipes se trompent en evaluant les politiques robotiques VLA ouvertes

La premiere erreur consiste a confondre la couverture de benchmark avec la couverture operationnelle. RoboCasa, RoboCasa365 et VLABench sont precieux parce qu'ils fournissent des environnements structures pour l'evaluation. La page projet de RoboCasa365 le decrit comme couvrant 365 taches et plus de 2 500 environnements de cuisine, avec plus de 600 heures de donnees de demonstration humaine et plus de 1 600 heures de demonstrations generees synthetiquement. Aucun benchmark ne peut prouver qu'une cellule de travail cible, une distribution d'objets, une configuration d'eclairage, une routine de reinitialisation et une frontiere de securite sont couvertes.

La deuxieme erreur consiste a sauter le mapping d'incarnation. L'entrainement sans incarnation ou multi-incarnations peut aider le modele a apprendre des motifs de manipulation transferables. Il ne garantit pas que votre pose de camera, votre pince, votre echelle d'action, votre repere de coordonnees ou le timing de votre controleur correspondent aux hypotheses de la politique.

La troisieme erreur consiste a mesurer le succes tout en ignorant la recuperation. Une route qui termine une tache dans des conditions propres mais se comporte mal apres une prise ratee n'est pas prete pour l'expansion. Le comportement de recuperation, la gestion des quasi-incidents, la detection hors distribution, l'arret securise et la politique de reinitialisation comptent souvent plus que des clips de succes isoles.

La quatrieme erreur consiste a traiter la latence comme une moyenne. Une route de politique peut avoir une moyenne acceptable et echouer quand meme a cause de la gigue, d'observations obsoletes ou de retards intermittents du serveur. Regardez les queues, pas seulement le centre de la distribution.

Plan de mesure : les preuves a collecter avant l'approbation de route

Un dossier d'approbation de route doit repondre a une question difficile : une autre equipe pourrait-elle inspecter la meme execution et comprendre exactement ce qui s'est passe ? Capturez le commit source, le hachage du checkpoint, la config, l'environnement, l'incarnation robotique, l'ID de calibration camera, la tache, la seed si applicable, l'instruction, la pile runtime, l'heure de debut et de fin, l'operateur et le mode de route. Capturez ensuite le resultat de la tache, la raison d'intervention, le quasi-incident, la collision, le declencheur hors distribution, le resultat de reinitialisation, l'activation du repli, l'evenement de rollback, la distribution de latence, la gigue, les observations perdues, les observations obsoletes et le mode d'echec observe.

Le cout par heure de tache acceptee est utile s'il est traite comme une metrique interne, pas comme une promesse universelle. Il peut combiner le temps materiel, la supervision operateur, le surcout de reinitialisation, le cout de calcul, la maintenance, les executions rejetees et le temps de tache reussi accepte. L'objectif est de comparer les routes sans masquer le travail de reinitialisation et le cout de supervision.

{
  "route_status": "shadow",
  "policy": "Xiaomi-Robotics-1 candidate route",
  "required_pins": ["repo_commit", "checkpoint_hash", "dependency_lock", "calibration_id"],
  "accepted_tasks": ["team_defined_after_canary"],
  "excluded_tasks": ["uncalibrated_or_high_risk_tasks"],
  "safety_gates": ["independent_human_stop", "workspace_limit", "fallback", "rollback"],
  "rollback_condition": "timing, recovery, OOD, collision, or reset behavior outside acceptance band",
  "unresolved_caveats": ["sim_to_real_gap", "benchmark_leakage", "calibration_drift", "model_weight_terms"]
}

Reserves, limites et prochaine etape pratique

Xiaomi-Robotics-1 merite d'etre evalue parce qu'il fournit du code public, des chemins de deploiement, des liens de checkpoints, des guides de benchmark, une page projet et un rapport technique. Cela rend possible une reproduction serieuse. Cela ne supprime pas les parties difficiles du deploiement robotique.

Les principales reserves sont le cout d'implementation, les ecarts simulation-reel, les fuites de benchmark ou les chevauchements de donnees, la variance des modeles et des fournisseurs, la confidentialite des donnees camera, la derive de calibration, les termes des assets tiers, les frontieres de certification de securite et les compromis operationnels. Ne deployez pas si les artefacts ne peuvent pas etre epingles, si l'evaluation ne peut pas etre reproduite, si les incarnations prises en charge ne correspondent pas au robot, si le timing est instable, si l'arret de securite n'est pas independant, si la recuperation est mauvaise, si la politique de reinitialisation est peu claire ou si le rollback depend d'heroisme manuel.

La prochaine etape pratique consiste a traiter Xiaomi-Robotics-1 comme une route candidate derriere R-PATH, pas comme un deploiement automatique. Reproduisez d'abord, epinglez les artefacts, alignez l'incarnation, testez le timing en boucle fermee et la recuperation, et gardez l'autorite humaine visible par les controles de canary et de rollback. Si votre equipe evalue des politiques robotiques ou d'autres routes d'automatisation IA, Optijara peut aider a concevoir des portes d'acceptation, de la telemetrie, des bancs d'evaluation et des plans de deploiement progressif qui relient les artefacts de recherche aux preuves operationnelles.