Isaac Sim, Nav2, production : ce que la simulation cache

Une pile de navigation qui tourne parfaitement dans NVIDIA Isaac Sim vous dit une chose avec certitude : votre code compile, vos transformations sont cohérentes, votre behavior tree fait ce que vous avez écrit. Elle ne vous dit presque rien sur la capacité d'une flotte à tenir une équipe complète en entrepôt sans que quelqu'un se déplace pour débloquer un robot.

La distance entre ces deux états, c'est le sim-to-real gap. Ce n'est pas un défaut du simulateur. Isaac Sim modélise le monde que vous lui avez décrit. L'écart vient de tout ce que vous n'avez pas décrit, et de paramètres Nav2 réglés en silence contre un monde qui n'existe pas. La suite décrit ce qui vit dans cet écart, et la discipline de validation qui en referme l'essentiel avant que les robots ne touchent le sol.

Ce qu'Isaac Sim modélise bien

• La géométrie et l'implantation. Largeur des allées, débords de rack, hauteurs de quai, encadrements de porte. Un passage que le robot ne franchit pas en simulation ne s'élargira pas dans le bâtiment.
• La dynamique des corps rigides. PhysX rend compte de manière crédible de la masse, de l'inertie et des contacts pour un châssis rigide sur un sol plat.
• La géométrie des capteurs. Là où le LiDAR est occulté par la structure du robot, ce que la caméra de profondeur ne voit pas sous le pare-chocs, où se placent les zones aveugles avec une charge haute.
• Le graphe ROS 2 complet. Topics, arbres TF, profils QoS, transitions de cycle de vie et behavior tree tournent pour de vrai. La majorité des bugs d'intégration meurent là.
• La répétabilité. Même scénario, même graine, même résultat. Aucun site réel ne vous offre ça.

Cette dernière propriété est celle que les équipes confondent avec de la validation. Un test que l'on rejoue à l'identique est un test de non-régression, pas une preuve que le système fonctionne.

Ce qu'il modélise mal

• Le bruit capteur avec sa vraie texture. Un retour LiDAR simulé est propre. Un vrai décroche sur le caoutchouc noir et les plastiques sombres mats, produit des retours parasites sur le béton lissé et le film étirable, et floute autour des bandes rétroréfléchissantes. La couche d'obstacles voit un nuage de points différent de celui sur lequel elle a été réglée.
• La dérive d'odométrie avec une cause physique. En simulation, l'odométrie dérive parce que vous l'avez décidé. En vrai, elle dérive parce qu'un pneu est sous-gonflé, qu'une roue folle shimmy, que la dalle a des joints de dilatation, ou qu'une charge déplace le centre de masse au freinage.
• L'adhérence. Poussière, film d'humidité près d'un quai, reprise en résine époxy dont le coefficient de frottement diffère du reste de la dalle, ressaut au passage d'un seuil. Le patinage de roue est une cause courante de perte de localisation, et il n'existe quasiment pas en simulation.
• Le temps. Sur le robot, la perception se dispute le CPU avec le contrôleur, l'itinérance Wi-Fi ajoute de la gigue à tout ce qui quitte le châssis, et une tempête de découverte DDS en début d'équipe peut bloquer un nœud assez longtemps pour déclencher une recovery.
• Les humains. Un piéton simulé suit une politique. Un cariste coupe le virage, un préparateur reste immobile dans une allée avec un casque sur les oreilles, un transpalette traîne à moitié dans le couloir. Le comportement humain a une longue traîne qu'aucune foule scriptée ne reproduit.
• Le changement dans le temps. La carte construite en semaine un décrit un bâtiment qui n'existe plus en semaine six. Les racks bougent, le stock saisonnier redessine les allées, une balle de carton apparaît là où il y avait de l'espace libre. Ajoutez des marquages au sol usés et un éclairage qui faiblit, et toute détection ou tout docking basé caméra dérive avec.

Le tuning Nav2 qui ne survit pas au transfert

Chacun des réglages ci-dessous est raisonnable en simulation, et chacun est à rouvrir le premier jour sur matériel réel.

L'inflation de la costmap est la première chose que les équipes serrent trop. En simulation la couche d'obstacles est nette, donc un petit inflation_radius avec un cost_scaling_factor agressif produit des trajectoires élégantes qui se faufilent. Sur le terrain, les mêmes valeurs placent le robot dans sa propre marge de sécurité dès qu'un retour parasite apparaît, et le planificateur se met à refuser des itinéraires qu'il empruntait la veille. L'inflation se règle sur du bruit capteur mesuré et sur l'incertitude réelle de localisation, pas sur un scan propre.

La footprint vient ensuite. Les équipes modélisent le châssis. Le robot livré a une charge en débord arrière, un contact de charge saillant, une antenne, et un contour qui change selon ce qu'il transporte. Si la footprint n'est pas l'enveloppe balayée réelle, charge comprise, la costmap ment au contrôleur.

Le choix du contrôleur compte davantage après le transfert qu'avant. DWB se raisonne facilement et se sur-règle tout aussi facilement sur un scénario simulé, et ses trajectoires échantillonnées supposent que le robot suit fidèlement la vitesse commandée. MPPI absorbe mieux l'erreur de modèle mais consomme du calcul qu'il ne vous reste peut-être plus après la perception, et son comportement change quand la boucle de contrôle rate ses échéances. Regulated Pure Pursuit est le choix pragmatique pour un robot différentiel sur de longues allées : peu de paramètres, comportement prévisible, régulation de vitesse propre en courbure et près des obstacles. La bonne question n'est pas lequel est le meilleur, mais lequel se dégrade d'une manière que votre exploitation peut assumer.

Les recovery behaviors ne sont presque jamais éprouvés honnêtement en simulation, parce que le robot simulé se coince rarement pour de vrai. En production, ils tournent en permanence. Une rotation de dégagement en allée étroite avec une charge à bord n'est pas la manœuvre qu'elle était dans un hall simulé vide, et vider la costmap pour échapper à un obstacle fantôme efface aussi la palette bien réelle qui se trouve là. Le collision monitor est une dernière ligne de défense, pas la seule.

La localisation est le domaine où la simulation vous flatte le plus. AMCL sur carte statique se comporte bien quand la carte est exacte, ce qu'elle est en simulation par construction. Dans un bâtiment en exploitation, la carte est un document historique. Le SLAM continu la garde à jour mais introduit son propre mode de défaillance : le robot cartographie joyeusement l'état temporaire du monde, puis lui fait confiance. Le compromis praticable consiste à tenir une carte statique maîtrisée pour la structure, à définir un processus de reprise de relevé, et à surveiller la santé de la localisation pour qu'un robot puisse déclarer qu'il est perdu au lieu de rouler avec assurance vers le mauvais endroit.

Ce qui casse en flotte et jamais sur un robot seul

Un robot qui navigue dans un bâtiment est un problème suffisamment résolu. Les défaillances intéressantes commencent au deuxième et se composent au dixième.

• La congestion n'est pas additive. Chaque robot apparaît dans la costmap de l'autre comme un obstacle mobile, les deux ralentissent, les deux replanifient, et cette replanification consomme le calcul qui leur aurait permis de se dégager vite.
• Les deadlocks aux points de passage. Une porte, un sas d'ascenseur, une section à voie unique autour d'un poteau. Deux robots se croisent, chacun cède, chacun replanifie dans la trajectoire de l'autre, et la paire oscille. Nav2 n'a aucune notion de l'intention de l'autre robot, seulement d'un obstacle qui a bougé.
• La divergence des cartes. Des robots qui mettent à jour leur propre carte finissent avec des vues différentes du même bâtiment, et un opérateur devant deux tableaux de bord ne peut pas trancher.
• Les ressources partagées. Bornes de charge, ascenseurs, portes et couloirs étroits demandent un arbitrage. Rien dans Nav2 ne les arbitre, et l'improviser dans le behavior tree de chaque robot produit un protocole distribué sans propriétaire.
• Les défaillances corrélées. Une coupure réseau, une dérive de synchronisation d'horloge ou une mauvaise carte poussée touchent tous les robots en même temps, en pleine équipe.

La réponse structurelle : la gestion du trafic est une couche au-dessus de la navigation. Nav2 pilote bien un robot. Qui passe en premier, qui possède un couloir, comment un ascenseur se réserve, cela appartient ailleurs, dans Open-RMF ou dans un fleet manager que vous construisez.

Une validation par paliers, avec des gates

La méthode qui marche est peu glorieuse. Chaque palier a un critère de sortie fixé avant de lancer les tests.

1. Tests de composants en simulation. Planificateur, contrôleur et behavior tree sur des scénarios figés avec assertions, à chaque commit.
2. Scénarios randomisés. Les mêmes tests rejoués avec frottement perturbé, modèles de bruit capteur, latence injectée, variation de masse et de centre de masse, changements de lumière et encombrement aléatoire. Ce que vous cherchez n'est pas un succès, c'est la frontière à partir de laquelle la pile lâche, et le fait qu'il reste ou non de la marge.
3. Rejeu contre du réel enregistré. Des bags pris dans le bâtiment lui-même, réinjectés dans la perception et la localisation. Le moyen le moins cher d'affronter du bruit capteur que vous n'avez pas inventé.
4. Hardware in the loop. Vrai calculateur, vrais drivers capteurs, vraie configuration DDS, le simulateur ne fournissant que le monde. Les problèmes de timing surgissent ici, et ils n'apparaissent jamais dans un run sur poste de travail seul.
5. Un robot sur le site réel, d'abord dans une zone balisée hors exploitation, puis en exploitation avec quelqu'un derrière lui. La deuxième étape sert à collecter les échecs, pas à prouver le succès.
6. Deux robots, puis la flotte, dans la zone la plus chargée plutôt que la plus facile. L'information que vous achetez, c'est le comportement en congestion.

Sauter un palier, c'est décider de l'apprendre plus tard, à un moment que vous ne choisirez pas.

Les métriques à instrumenter

Les métriques qui comptent sont opérationnelles plutôt qu'académiques, et toutes doivent être décidées avant le déploiement. Ajouter l'observabilité après coup sur une flotte en service est un projet nettement plus difficile.

• Le taux d'intervention humaine, avec un code de cause à chaque fois qu'une personne touche un robot. C'est le chiffre qui décide si le déploiement tient économiquement.
• La distance et le temps entre replanifications. Une fréquence de replanification qui monte sur une zone est le premier signal que la carte, le tuning ou l'implantation ont dérivé.
• Le temps bloqué, ventilé par cause : attente d'une personne, d'un autre robot, d'une porte, ou blocage réel.
• Les déclenchements de recovery par type et leur taux de succès. Une recovery qui part souvent et réussit masque un problème. Une recovery qui part souvent et échoue est le problème.
• La santé de la localisation : covariance de pose, score de correspondance à la carte, nombre de relocalisations par équipe.
• Les quasi-collisions et les arrêts d'urgence, avec les secondes de données capteur qui précèdent.

Deux pratiques rendent ces chiffres exploitables. Journaliser à une finesse qui permet de reconstituer un incident, ce qui signifie un buffer circulaire de données capteur brutes et de TF, figé sur détection d'anomalie. Et les relire à cadence fixe avec les gens du terrain, parce que l'opérateur qui dit que les robots sont devenus bizarres près du poste d'emballage décrit un vrai signal bien avant qu'un graphe ne le montre.

Ce que cela demande à une équipe

• Quelqu'un qui porte la simulation comme un produit : couverture de scénarios, paramètres de randomisation, honnêteté sur ce qu'elle ne modélise pas.
• Quelqu'un qui porte la vérité physique : calibration, montage des capteurs, variabilité des roues et des charges, et le bâtiment traité comme un objet qui change.
• De l'ingénierie data et observabilité, parce que la télémétrie d'une flotte réclame un pipeline, pas un dossier de bags.
• Une boucle de retour terrain avec un nom et une fréquence. L'exploitation remonte une panne, l'ingénierie la reproduit en simulation, le scénario rejoint la suite de non-régression, le correctif remonte les paliers. Une panne que personne ne sait reproduire en simulation après coup est elle-même un trou dans la simulation.
• De la discipline de déploiement. Un changement de paramètre Nav2 poussé sur une flotte est une mise en production : déploiement progressif, chemin de retour arrière.

La culture compte autant. Une équipe qui traite une intervention terrain comme une honte cesse de les remonter. Une équipe qui en fait à chaque fois un scénario de plus progresse chaque semaine.

Ce qu'il faut en retenir

Isaac Sim n'est pas le problème, et aucun gain de fidélité ne le rendrait suffisant. La simulation élimine les défaillances que vous savez décrire. Tout ce que vous n'avez pas su décrire attend dans le bâtiment, et le chemin qui traverse passe par une validation par paliers, une instrumentation posée avant d'en avoir besoin, et une boucle de retour qui transforme chaque panne terrain en test permanent.

Les équipes qui livrent des flottes qui tournent ne sont pas celles qui ont la simulation la plus photoréaliste. Ce sont celles qui ont supposé que la simulation avait tort, et construit le processus pour savoir où.

Abbeal construit et accompagne des équipes d'ingénierie depuis ses hubs de Paris, Montréal et Tokyo, robotique et ROS 2 compris. Si vous faites passer une pile de navigation de la simulation à une flotte en production et que vous voulez discuter de l'approche de validation, écrivez-nous.