Test d'acceptation de simulation robotique Newton Physics 1.5 : le guide RSRAT pour la préparation à l'entraînement par lots

Un simulateur peut réussir une démonstration et échouer quand même sur le parcours d'entraînement. La scène rendue n'est pas le problème. Le problème commence lorsque des centaines de mondes robotiques avancent en parallèle, qu'une voie se termine tôt, qu'une réinitialisation touche un état qu'elle ne devrait pas toucher, ou qu'un cas limite de contact se cache dans une courbe de récompense moyenne.

C'est la question pratique derrière Newton Physics 1.5. La version GitHub identifie v1.5.0 comme une version fonctionnelle après v1.4.0, avec des notes sur la simulation par lots évolutive, les flux de contrôle robotique, la fiabilité des contacts, la fidélité d'importation des assets, la mécanique des câbles, ainsi que des chemins MuJoCo et Kamino activables. C'est utile, mais cela ne suffit pas à donner un feu vert. Une version peut ajouter des fonctionnalités utiles alors que le robot, les assets, les contrôleurs et la pile d'entraînement propres à une équipe nécessitent encore une qualification.

Cet article transforme la version en Robot Simulation Route Acceptance Test d'Optijara, ou RSRAT. Ce n'est pas un benchmark officiel de NVIDIA ou de Newton. C'est un test opérationnel de consultant pour décider si Newton 1.5 doit rester en usage de démonstration, passer à un canari limité, ou prendre en charge un entraînement robotique par lots plus large. Pour une réflexion voisine sur les tests d'acceptation, consultez le guide d'Optijara sur l'acceptation du parcours de politiques Xiaomi-Robotics-1, les leçons de validation en périphérie dans l'acceptation du pipeline vidéo JetPack 7.2.1, et le modèle de preuves pour pipeline de données dans l'acceptation du moteur de données multimodal Vane 0.1.0.

Pourquoi Newton Physics 1.5 a besoin de preuves de parcours

Les notes de version de Newton 1.5 mentionnent le contrôle vectorisé expérimental des articulations via newton.controllers, les flux multi-mondes, les réinitialisations masquées du solveur, une gravité dédiée pour le monde global, le sleeping MuJoCo Warp activable, la génération hydroélastique déterministe, la géométrie persistante, la réinitialisation sélective, les manifolds de boîtes stables, les aides pour câbles, et des correctifs lourds sur les contacts. Le dépôt et la page développeur de NVIDIA présentent Newton comme un moteur physique open source pour la robotique et les flux d'IA physique. Warp, Isaac Lab et MuJoCo MJX ajoutent le contexte autour des kernels GPU, des environnements d'apprentissage par renforcement robotique et de la simulation MuJoCo orientée JAX.

La question d'acceptation est plus étroite. Votre parcours à travers ces fonctionnalités produit-il des preuves répétables pour vos robots et vos scènes ? Une importation USD peut réussir tout en modifiant le comportement de collision. Un chemin MJCF peut préserver le fichier mais déplacer les hypothèses du contrôleur. Une exécution par lots peut signaler du débit pendant qu'une voie en échec contamine l'échantillon d'entraînement. Les améliorations de contact nécessitent encore des vérifications par replay sur les scènes qui comptent réellement pour vous.

La taille du lot est un indicateur faible de préparation. Le meilleur signal est de savoir si les pires voies restent visibles, isolées et explicables. RSRAT pousse les équipes vers cette norme. Il demande des verrouillages de version, la parité des importateurs, l'isolation des réinitialisations, le stress des contacts, le replay des contrôleurs, des limites de canari et la responsabilité du rollback. Cette même habitude de trace de preuves apparaît dans le test de trace de preuves Cloudflare Radar Researcher d'Optijara, où une affirmation n'est utile que lorsque le parcours peut être reproduit.

Le parcours RSRAT : cinq portes avant le passage à l'échelle

Chaque porte RSRAT retourne un état de parcours. Réussite signifie que le parcours peut continuer. Surveillance signifie qu'il ne peut continuer que dans un canari nommé avec un suivi strict. Échec signifie que la charge de travail reste limitée à la démonstration jusqu'à ce que le défaut soit corrigé ou que le périmètre soit réduit.

Porte 1 : Verrouillage de la version et de l'environnement

Commencez par verrouiller la page de version de Newton, le tag, le commit, les versions de dépendances, le pilote GPU, le runtime, la version de Warp, la couche d'intégration, les hachages de scènes et les paramètres du solveur. La page de version v1.5.0 fournit l'identité de la version et la preuve de commit. Cet enregistrement n'est pas de la paperasse. C'est ce qui permet à un ingénieur de reproduire plus tard une mauvaise trace de contact.

Porte 2 : Parité d'importation des assets

Vérifiez que les chemins USD et MJCF préservent les articulations, les limites, les masses, les formes de collision, les capteurs, les actionneurs et les hypothèses du contrôleur. Isaac Lab est un point de référence pertinent pour de nombreux flux robotiques centrés sur USD. MuJoCo MJX est un point de référence pertinent pour les chemins MJCF orientés JAX. Charger le fichier n'est pas une acceptation. Faire correspondre les hypothèses physiques est l'acceptation.

Porte 3 : Isolation des mondes par lots

Newton 1.5 met en avant les réinitialisations masquées du solveur, une gravité dédiée pour le monde global et le travail de réinitialisation sélective. RSRAT demande aux équipes de prouver l'isolation avec des hachages d'état, des graines aléatoires, des tampons de contact, des traces de récompense et des vérifications d'intégrateur de contrôleur pendant qu'une voie se réinitialise et que ses voisines continuent d'avancer.

Porte 4 : Stabilité des contacts et des contrôleurs

Les scènes riches en contacts sont celles où les démonstrations soignées peuvent commencer à montrer des faiblesses. Rejouez les cas de préhension, de glissement, d'empilement, d'impact et les cas hydroélastiques qui correspondent à la tâche prévue. Pour les contrôleurs, rejouez les exécutions nominales et les départs perturbés, puis inspectez la saturation des actionneurs, la dérive de l'intégrateur et la récupération après de mauvais états.

Porte 5 : Contrôle du rollout et de la régression

Une mise à niveau de simulateur nécessite un propriétaire de parcours, un périmètre de canari, un chemin de repli et un déclencheur de rollback. C'est particulièrement vrai pour les équipes qui utilisent la simulation dans un pipeline d'entraînement, où un défaut discret du simulateur peut consommer du temps de calcul avant que quelqu'un voie la mauvaise hypothèse.

Porte 1 : Épingler Newton 1.5 et définir la reproductibilité

Construisez un manifeste avant les tests de performance. Enregistrez la version de Newton, le tag et le commit, l'URL source de Newton, la version de Warp, l'environnement Python, les détails CUDA et du pilote GPU, le système d'exploitation cible, la couche d'intégration, les hachages de scènes, les paramètres du solveur, la configuration du contrôleur, la politique de graines aléatoires et la version du lanceur de tests. Si le parcours touche Isaac Lab, enregistrez la version d'Isaac Lab et les définitions de tâches. S'il touche MuJoCo ou MJX, enregistrez la source XML ou MJCF et les paramètres MJX.

Gardez les étiquettes visibles. La version Newton 1.5 qualifie le contrôle vectorisé des articulations d'expérimental et le sleeping MuJoCo Warp d'option activable. Ces étiquettes doivent suivre la fonctionnalité jusque dans la décision de parcours. Les fonctionnalités expérimentales peuvent être évaluées, mais elles ne doivent pas devenir discrètement une infrastructure requise. Les chemins liés aux câbles, aux déformables, à l'hydroélastique et à d'autres contacts lourds exigent la même discipline, car ils sont sensibles aux paramètres du solveur, à la géométrie et à la conception de la tâche.

Définissez la reproductibilité avant la vitesse. Une exécution plus rapide qui ne peut pas être rejouée constitue une preuve fragile. Les signaux utiles incluent les signatures de replay à graine fixe, les sommes de contrôle d'épisodes, les comptes d'événements de contact, les sommes de contrôle d'état de réinitialisation, le temps de pas en queue, le taux de NaN ou d'explosion, et la dérive de régression par rapport à un corpus connu. Ces métriques ne prouvent pas le transfert de la simulation vers le réel. Elles prouvent si le parcours de simulation est suffisamment contrôlé en interne pour soutenir des expériences d'entraînement.

Porte 2 : Tester la fidélité d'importation USD et MJCF

Les vérifications d'importateur doivent être strictes et un peu ennuyeuses. L'échec d'importation le plus coûteux est souvent petit : un axe d'articulation qui a bougé, une propriété de masse qui a changé, une approximation de collision qui modifie le glissement, ou un mapping d'actionneur qui donne à une politique la mauvaise observation.

Exécutez les vérifications simulation à simulation avant l'entraînement. Utilisez de petites scènes, des graines fixes et des contrôleurs de référence. Comparez les enveloppes de trajectoire, pas seulement la récompense finale. Si une charge de travail utilise USD via Isaac Lab et qu'une autre utilise MJCF via MuJoCo ou MJX, traitez-les comme des parcours séparés avec des manifestes séparés. Ne laissez pas un résultat propre dans un chemin blanchir le risque dans l'autre.

Porte 3 : Prouver l'isolation des réinitialisations sélectives

Le test central de RSRAT est l'isolation des réinitialisations sélectives. Construisez un lot avec plusieurs mondes : une voie conçue pour se terminer tôt, une avec du stress de contact, une scène de référence calme et une famille d'assets différente. Réinitialisez une voie pendant que les autres continuent. Comparez ensuite les hachages d'état avant et après réinitialisation, les graines aléatoires, les tampons de contact, les traces de récompense, les tampons de contrôleur et les drapeaux de terminaison.

Une réussite n'exige pas que chaque valeur en virgule flottante corresponde sur chaque appareil. Elle exige des preuves que les critères d'acceptation du parcours sont suffisamment stables pour la charge de travail. La voie réinitialisée ne doit pas modifier les récompenses, les tampons de contact ou les intégrateurs de contrôleur voisins. Une voie en échec ne doit pas disparaître dans les métriques au niveau du lot. La randomisation doit rester dans les limites déclarées, afin qu'un paramètre global comme la gravité ne change pas les hypothèses des mondes voisins, sauf si c'est l'expérience.

Testez par paliers. Commencez avec un petit lot où les défauts sont faciles à inspecter. Passez à un lot mixte avec différentes scènes et familles de robots. Exécutez ensuite un lot de stress qui approxime la forme d'entraînement prévue. Suivez la tendance de débit, la marge de mémoire GPU, le temps de pas en queue, les échecs d'isolation des réinitialisations et la reproductibilité des épisodes. Le débit moyen seul ne suffit pas, car le parcours d'entraînement échoue souvent dans la queue.

Porte 4 : Stresser les contacts, les contrôleurs et le comportement de sommeil ou de réveil

Les notes de version de Newton 1.5 indiquent une meilleure gestion des contacts, y compris la génération hydroélastique déterministe, la géométrie persistante, la réinitialisation sélective, les manifolds de boîtes stables, le couplage proxy VBD pleine surface et des correctifs de capacité dans les chemins pertinents. Traitez ces notes comme des raisons d'écrire des tests plus précis.

Rejouez des scénarios riches en contacts qui représentent le parcours : pinces se fermant sur des objets, boîtes qui s'empilent et glissent, impacts, interactions avec câbles ou déformables le cas échéant, et scènes hydroélastiques si la charge de travail les utilise. Comparez les distributions de comptes de contact, les scènes aberrantes, les symptômes de pénétration ou de glissement, et la récupération après perturbation. Une certaine variation numérique est normale. Des explosions répétées, une dérive inexpliquée, des NaN ou des régressions propres au parcours ne le sont pas.

Les tests de contrôleur doivent inclure des graines nominales, des départs perturbés et des conditions de latence de queue. Surveillez la saturation des actionneurs, la dérive de l'intégrateur, la récupération instable et les traces de récompense qui paraissent bonnes uniquement parce qu'une voie en échec a été diluée dans la moyenne. Si le parcours utilise le contrôle vectorisé expérimental des articulations, gardez cette étiquette dans la décision de parcours. S'il utilise le sleeping MuJoCo Warp activable, testez le comportement de réveil dans les scènes où des arbres articulés inactifs deviennent actifs après contact.

La matrice de décision RSRAT

La matrice de décision transforme les preuves en parcours. Elle est conservatrice par conception, car l'acceptation du simulateur coûte moins cher que l'entraînement sur des données contaminées.

La démonstration uniquement convient à l'exploration et à la visualisation. Un parcours canari convient aux preuves majoritairement solides, mais avec un risque nommé dans un ensemble limité de scènes ou une famille de robots limitée. L'entraînement par lots élargi exige des portes réussies, des preuves stockées sous forme lisible par machine et des déclencheurs de rollback que l'équipe utilisera réellement.

La conception du canari doit inclure un petit corpus de régression, une forme de lot limitée, un simulateur de repli connu ou un chemin de version précédente, des seuils propres au parcours et un propriétaire. Revenez en arrière lorsque la parité d'importation casse des assets critiques, que les réinitialisations sélectives fuient de l'état, que le comportement de contact devient instable, que le replay du contrôleur diverge ou que les métriques du canari échouent aux critères convenus.

Checklist de mise en oeuvre et plan de mesure

Utilisez cette checklist avant d'élargir un parcours Newton 1.5.

{
  "framework": "RSRAT",
  "simulatorVersion": "Newton Physics v1.5.0",
  "sourceUrls": ["https://github.com/newton-physics/newton/releases", "https://github.com/newton-physics/newton"],
  "importRoutes": ["USD", "MJCF"],
  "batchSizes": ["small", "mixed", "stress"],
  "resetIsolationStatus": "pass-watch-fail",
  "contactRepeatabilityStatus": "pass-watch-fail",
  "canaryDecision": "demo-only | limited-canary | expanded-training",
  "rollbackPlan": "owner, trigger, fallback route"
}

La mesure doit couvrir la marge de mémoire GPU, la tendance de débit, le temps de pas en queue, les échecs d'isolation des réinitialisations, les valeurs aberrantes de contact, le taux de NaN ou d'explosion, la reproductibilité des épisodes et la dérive de régression. Les équipes qui ont besoin d'un banc d'essai indépendant peuvent adapter RSRAT en interne ou demander à Optijara d'en faire un flux de qualification de simulateur mesuré, lié à leur pile d'entraînement et d'automatisation.

Ce que les équipes se trompent souvent

Erreur 1 : Traiter le succès d'importation comme une parité physique

Une scène qui se charge n'est pas nécessairement une scène qui préserve les hypothèses de contrôle. Corrigez cela avec des tableaux de parité d'importateur, des scènes de référence et le replay du contrôleur avant le début de l'entraînement.

Erreur 2 : Diluer les échecs de queue et de réinitialisation dans la moyenne

Les moyennes de lots peuvent cacher la voie en échec. Suivez le temps de pas en queue, les échecs d'isolation des réinitialisations, les valeurs aberrantes de contact et la reproductibilité au niveau de l'épisode. Si une voie explose, le parcours doit le rendre visible.

Erreur 3 : Élargir les lots avant l'existence du rollback

Un canari sans rollback n'est qu'une expérience plus grande. Définissez le simulateur de repli ou le parcours Newton précédent, le propriétaire, les conditions d'arrêt et les preuves nécessaires pour reprendre.

Erreur 4 : Survendre les preuves de transfert simulation vers réel

L'acceptation du simulateur peut réduire des risques internes connus. Elle ne prouve pas le transfert physique. Le transfert vers le monde réel exige une validation physique, des preuves propres à la tâche, une revue de sûreté et des limites soigneuses sur ce que signifie le résultat de simulation. RSRAT est utile parce qu'il rend le parcours de simulation plus auditable avant que les équipes dépensent du calcul d'entraînement sur des preuves faibles.