Vitrine Mission Control

Utilisez le runner groupé pour la vitrine Nova Carter small-warehouse par défaut. Il possède l'intégration et coordonne cinq skills upstream qu'il résout à l'exécution plutôt que de les vendorer. Résolvez ces dépendances une fois avec scripts/doctor.py dependencies --prepare avant la première exécution.

Sélection à l'exécution

Lancez toujours Isaac Sim à partir d'une installation locale via ce runner de vitrine, avec sa fenêtre GUI sur l'affichage hôte. Observez le robot dans cette fenêtre. Pilotez chaque opération d'étape via le serveur Python isaac-sim-remote sur ISAAC_PYTHON_PORT. Il n'y a pas de WebRTC, de visionneuse navigateur, ou d'Isaac Sim conteneurisé dans ce workflow.

Avant le check de préparation, inspectez l'état existant en lecture seule. Déterminez le chemin d'installation et la version, si isaac-sim.sh et les bibliothèques ROS 2 bridge groupées sont présentes, si un affichage est disponible, et si une instance Isaac Sim est déjà en cours d'exécution. Ne lancez ni n'importez Isaac Sim, ne démarrez ni n'arrêtez de conteneur, n'exécutez d'installateur, et n'altérez de fichiers.

Traitez la version installée, l'URI du warehouse, les graphes d'actifs et de capteurs Nova Carter, et les sondes de préparation comme un ensemble de compatibilité. La seule présence d'Isaac Sim ne prouve pas la compatibilité.

Appliquez cette politique de sélection :

• Si une installation 6.0 est présente à ISAAC_SIM_DIR, signalez la version détectée et continuez sans prompt inutile.

• Si une version différente est détectée et que le launcher, le bridge ROS 2, et un URI de warehouse vérifié sont tous présents, utilisez-la automatiquement — sans prompt — et signalez le choix :

  Isaac Sim <version> détecté à <path> et est utilisable (launcher <ready/status>, ROS 2 bridge <ready/status>). Utilisation de cette installation.

  Tentez le check de préparation normal et le contrat de préparation ; arrêtez et signalez une incompatibilité plutôt que de modifier cette installation.

• Invitez l'utilisateur avant le check de préparation uniquement quand la version ne peut pas être déterminée, ou qu'aucun launcher, ROS 2 bridge, ou URI de warehouse vérifié ne peut être confirmé — c'est le seul cas de sélection à l'exécution qui demande une entrée utilisateur, car aucun choix automatique ne peut être vérifié sûr :

  Isaac Sim <version> a été détecté à <path>. Launcher : <ready/status>. ROS 2 bridge : <ready/status>. Choisissez d'utiliser la version détectée ou sélectionner ou installer une autre version.

• Docker est encore requis pour la stack cloud Mission Control et Nova Carter SIL, mais jamais pour Isaac Sim lui-même.

• Si rien n'est installé, routez vers le skill isaac-sim-installation résolu plutôt que de deviner un chemin. Résolvez-le via scripts/doctor.py dependencies ; ne le recherchez jamais et ne vendorisez jamais une copie.

Ne mettez jamais à jour, à jour antérieure, ne remplacez, supprimez, réparez, ne relabelez, n'actualisez, ou ne modifiez autrement une installation Isaac Sim existante comme récupération de vitrine. Obtenez une direction utilisateur explicite avant d'arrêter une instance Isaac Sim déjà en cours d'exécution.

Si l'utilisateur demande d'installer, mettre à jour, rétrograder, ou obtenir autrement une version Isaac Sim différente, arrêtez le workflow de vitrine et remettez au skill isaac-sim-installation résolu. Lisez son SKILL.md à l'exécution au chemin que le manifeste de dépendance rapporte, et suivez ses propres gates sans en contourner aucun. Ne reproduisez pas ou ne retraciez sa logique d'installation ici. Le runner demande une installation locale autonome, donc présélectionnez cette méthode. Arrêtez après que le chemin d'installation soit rapporté ; ne lancez pas Isaac Sim. Reprenez la sélection à l'exécution uniquement après que cette remise soit terminée et l'utilisateur demande de continuer. Quand ce skill exécute un check de compatibilité, préférez un --timeout-seconds généreux tel que 3600 ; son défaut de 600 secondes expire souvent sur une première exécution qui peuple encore les caches de shader et d'actifs.

Workflow par défaut

1. Vérifiez si l'utilisateur a déjà spécifié une carte, plateforme robot, simulateur, ou objectif de mission différent dans la conversation ; sinon, utilisez le défaut canonique sans demander.

2. Appliquez la Sélection à l'exécution sans modifier aucune installation détectée. Résolvez tout choix utilisateur ou remise d'installation, puis exécutez le check de préparation en lecture seule :

   skills/isaac-mission-control-showcase/scripts/run.sh --preflight

3. Demandez à l'utilisateur d'arrêter ou de relocaliser chaque conteneur en cours d'exécution signalé qui n'est pas explicitement autorisé. Autorisez les charges de travail non liées par nom de conteneur exact avec un --ignore-container NAME répété ; les conteneurs ignorés subissent encore les checks de conflit de port normaux. N'arrêtez pas une instance Isaac Sim automatiquement. Demandez un ISAAC_PYTHON_PORT libre.

4. Démarrez la stack et laissez le robot inactif :

   skills/isaac-mission-control-showcase/scripts/run.sh

5. Ou exécutez la route fermée déterministe et attendez la fin :

   skills/isaac-mission-control-showcase/scripts/run.sh --demo

6. Observez le robot dans la fenêtre Isaac Sim que le runner ouvre. Le runner charge la scène avant que Carter ne démarre, donc le mouvement initial du robot reste visible.

7. Arrêtez uniquement les ressources de vitrine enregistrées :

   skills/isaac-mission-control-showcase/scripts/run.sh --stop

Chaque exécution écrit run-manifest.json dans son répertoire de travail avant que quoi que ce soit ne démarre et le met à jour à chaque transition, donc une exécution interrompue peut encore être décrite et arrêtée précisément. run-result.json est l'artefact d'acceptation lisible par machine. Inspectez une exécution, y compris une qui a été interrompue, avec :

skills/isaac-mission-control-showcase/scripts/showcase.py \
  run-status --work-dir <dir>

Un arrêt ne cible que les conteneurs qui tournent enregistrés, est idempotent, et préserve les logs et les preuves. Les preuves de mouvement sont persistées quand observées, donc un échantillon ultérieur stationnaire ne remplace jamais une observation confirmée. L'acceptation reste stricte peu importe : mission COMPLETED, robot en ligne, sain et IDLE, mouvement confirmé, pas d'OOM, processus obligatoires sains.

Consultez references/troubleshooting.md pour les états du cycle de vie, la procédure de récupération, les verdicts de mouvement, la gestion de la sortie d'Isaac Sim, la politique de mémoire hôte, et le check d'exécutable du bridge ROS 2.

Le runner crée un répertoire frais sous ${TMPDIR:-/tmp}, en imprime le chemin, et y écrit toute la configuration Mission Control générée, les cartes, les caches Isaac, les logs, et l'état. Il ne doit pas créer de fichiers à l'exécution dans le répertoire de travail de l'appelant. Si le démarrage ou l'exécution de la démo échoue après que le conteneur Nova Carter soit créé, le runner sauvegarde sa sortie ROS 2 launch complète datée dans $SHOWCASE_WORK_DIR/logs/nova-carter-ros2.log. Il rafraîchit le même log après l'arrêt de Nova Carter avec --stop.

Modèle de composition

Deux couches.

Groupée et propriété du parent — tout dans ce paquet : references/, shared/, scripts/, assets/, config/. L'arborescence references/ contient les adaptateurs d'intégration et les contrats de routage écrits pour cette vitrine. Ce ne sont pas des copies de skills upstream.

Résolue à l'exécution — les cinq skills que la vitrine orchestre. Ils sont possédés par leurs propres dépôts, lus et invoqués à partir de checkouts épinglés en dehors ce paquet, et jamais copiés.

upstream-versions.lock.json est la seule déclaration de dépendance : les deux dépôts GitHub publics, leurs refs épinglés et commits immuables, et les entrypoints et ressources obligatoires de chaque skill.

Résolvez une fois par hôte, puis exécutez :

python3 scripts/doctor.py dependencies --prepare \
  --env-file "$HOME/.mission-control-showcase/state/showcase-deps.env"

scripts/doctor.py exécute les deux phases : dependencies résout les skills upstream et écrit le manifeste, host vérifie cette machine. La phase de dépendance doit réussir en premier, car la phase hôte reçoit les entrypoints qu'elle a résolus.

Lisez references/workflow.md pour le routeur d'étape, et le README.md de chaque référence avant d'utiliser cette étape.

Utiliser un skill upstream

La référence vous dit où est upstream ; upstream vous dit comment il se comporte.

1. Lisez son SKILL.md à l'exécution, au chemin que le manifeste enregistre en tant que skills.<name>.skill_md. Rien dans ce paquet ne le restate.
2. Suivez ses propres gates, y compris la confirmation, les licences, et les gates d'approbation d'exécution.
3. Invoquez-le via l'adaptateur de référence, qui l'exécute à partir de son propre répertoire skill pour que les ressources relatives se résolvent là.
4. Ne le réimplémentez jamais, ne le vendorisez jamais, et ne substituez jamais une autre copie trouvée sur la machine.

N'invoquez pas bring-up-cloud-stack avec --with-sim ; cela démarre le mission-simulator générique, pas Nova Carter SIL. La vitrine possède Nova SIL, le lancement et l'arrêt d'Isaac Sim, la restauration de scène, la préparation inter-domaines, la soumission de mission, et la preuve d'accomplissement.

Dépendances manquantes

Le runner effectue un check de fraîcheur en lecture seule et les adaptateurs consomment le manifeste persisté. L'exécution normale ne clone jamais, ne récupère, tire, installe, ou ne met à jour quoi que ce soit.

Avec MISSION_CONTROL_SHOWCASE_REQUIRE_PREFLIGHT=1, une référence qui ne peut pas charger un manifeste prêt bloque plutôt que de revenir à la découverte. Un adaptateur quitte avec le code 3 avec BLOCKED [<component>]: … nommant le skill, ce qui était attendu, et la commande de check de préparation. Ne contournez jamais un bloqueur en vendorisant un skill.

Défaut canonique

Le défaut est :

• Isaac Sim : une installation locale à ISAAC_SIM_DIR (défaut ~/isaacsim), lancée avec sa fenêtre GUI. Isaac Sim 6.0 est le dernier runtime known-good. C'est un défaut, pas un plafond de compatibilité.
• Warehouse : https://omniverse-content-production.s3-us-west-2.amazonaws.com/Assets/Isaac/6.0/Isaac/Environments/Simple_Warehouse/warehouse.usd.
• Nova Carter SIL : nvcr.io/nvidia/isaac/nova_carter_sil:release-3.2.
• Pilote NVIDIA R590 ou plus récent.
• Un hôte classe 64 GB avec au moins 48 GB disponibles avant le démarrage et 4 GB d'espace swap libre.
• Nova Carter SIL est limité à 20 GB RAM plus jusqu'à 4 GB swap.
• Identité robot : carter01.
• Serveur Python Isaac Sim sur le port 8226.
• Websocket MQTT sur le port 9001, correspondant à la stack Mission Control packagée.
• Domaine ROS 77 pour Isaac Sim et Carter SIL, avec transport hôte normal. Le domaine isolé empêche les participants DDS du domaine-0 non liés d'épuiser la mémoire de Carter SIL tout en préservant la découverte Isaac-vers-SIL.

L'URI exact du warehouse est passé dans Isaac Sim et vérifié après le chargement de la scène. Ne découvrez jamais le warehouse via get_assets_root_path, un cache local, un checkout source, ou une recherche de système de fichiers.

Le runner configure Mission Control et démarre la cloud stack, puis lance Isaac Sim et restaure la scène pendant que le cloud s'initialise. Carter SIL démarre en dernier, donc la fenêtre Isaac Sim montre le mouvement initial du robot.

Pour une version Isaac non-canonique sélectionnée par l'utilisateur qui est déjà installée :

1. Demandez une installation compatible et un URI d'actif canonique.

2. Passez les deux explicitement :

   ISAAC_SIM_DIR=<resolved-install-path> \
   WAREHOUSE_USD_URI=<resolved-uri> \
     skills/isaac-mission-control-showcase/scripts/run.sh

3. N'inférez pas un futur URI en substituant un numéro de version. Une installation locale ne porte aucune balise de version inspectable, donc l'appelant possède le contrat d'actif.

4. Si la version demandée n'est pas déjà installée, arrêtez et remettez à isaac-sim-installation ; ne l'installez pas à l'intérieur de ce workflow.

Identité robot

carter01 n'est que le défaut. Définissez une autre identité avec soit :

skills/isaac-mission-control-showcase/scripts/run.sh \
  --robot-name my_robot --demo

soit ROBOT_NAME=my_robot.

Le runner applique la même valeur à la configuration de flotte Mission Control, Mission Client serial_number, noms de clients du bridge MQTT, sondage de préparation, et soumission de mission. Ne changez pas uniquement la charge de mission.

Route déterministe

La relecture par défaut est une route fermée :

[
  {"x": -5.1, "y": 1.4},
  {"x": -2.625, "y": 1.2},
  {"x": -0.2, "y": -2.075},
  {"x": -2.625, "y": -5.35},
  {"x": -5.1, "y": 1.4}
]

Soumettez-la comme mission route-seule avec timeout 900 et solveur NVIDIA_CUOPT. N'ajoutez pas de localisation de départ/fin ou d'itérations.

Pour des coordonnées personnalisées, d'abord amenez la stack sans --demo, capturez les points demandés via nearest_nodes WPG, validez avec visualize_route, et soumettez uniquement les points routables résultants.

Contrat de préparation

Le runner ne doit pas soumettre de mission jusqu'à ce que tous ceux-ci soient observés :

• la scène canonique est active et la timeline Isaac est en lecture ;
• ROS /clock avance ;
• une /scan LaserScan active utilise le cadre front_2d_lidar et a un timestamp dans une seconde du temps de simulation ;
• TF résout le cadre LiDAR dans map à ce timestamp de capteur exact ;
• map -> base_link se résout ;
• la pose du robot se trouve à l'intérieur de la costmap globale active ;
• les nœuds du cycle de vie du planificateur, contrôleur, et navigateur Nav2 sont actifs ;
• Carter SIL n'a enregistré aucun événement cgroup OOM et ses processus obligatoires de carte, localisation, planification, contrôle, navigation, et mission-client restent en vie ;
• Mission Control rapporte le robot configuré en ligne, IDLE, sans erreur, position-initialisée, et près de la pose de réinitialisation.

Traitez une miss TF LiDAR exact-time initiale comme une condition de démarrage limitée. Continuez à consommer des échantillons de scan plus récents jusqu'à ce qu'un se résolve dans map, ou échouez au deadline de préparation avec le dernier timestamp mesuré. Ne remplacez jamais cela par une recherche TF latest.

En cas d'échec, signalez l'observation échouée et les valeurs mesurées. Ne prétendez pas une racine cause de clock, TF, costmap, ou permission sans ces mesures.

Le carter_warehouse_navigation.png groupé et le YAML associé sont la ressource de carte unique. L'exécution copie cette paire dans la configuration générée Mission Control et le montage read-only /maps de Carter SIL. Mission Control utilise le même PNG et métadonnées pour générer la ressource WPG sous carter_warehouse_navigation.png. Le runner vérifie la source, Mission Control, et les hashs Carter avant le démarrage, puis vérifie l'identité WPG active, l'option de lancement Carter, et les octets montés par conteneur. Ne changez jamais récursivement les permissions sur un arborescence source ou n'appliquez une correction de permission après le démarrage des services.

Modes et remplacements

• --preflight : checks en lecture seule sur l'installation, affichage, Docker, GPU, dépendance, port, image, et actif.
• sans drapeau : démarrage propre et validation complète de préparation, laissant le robot inactif.
• --demo / --replay : démarrage, préparation, mission circulaire, accomplissement canonique de mission, et preuve de mouvement de pose.
• --stop : arrêtez la dernière stack enregistrée et SIGTERM le processus Isaac Sim, sans supprimer conteneurs, images, volumes, caches, ou logs.
• --dry-run : imprimez les commandes résolues sans modifier l'état à l'exécution.
• --work-dir PATH : utilisez un répertoire à l'exécution nouveau ou vide sélectionné par l'appelant.
• --no-pull : demandez que les images requises soient déjà locales.
• --ignore-container NAME : autorisez un conteneur déjà en cours d'exécution par nom exact lors du check de préparation et du démarrage ; répétez l'option pour chaque conteneur autorisé. Les conflits de port restent des échecs.

Les remplacements d'environnement supportés sont ISAAC_SIM_DIR, WAREHOUSE_USD_URI, NOVA_CARTER_IMAGE, NOVA_CARTER_MEMORY_LIMIT, NOVA_CARTER_MEMORY_SWAP_LIMIT, ROBOT_NAME, SHOWCASE_GPU_DEVICE, SHOWCASE_ROS_DOMAIN_ID, SHOWCASE_ROS_LOCALHOST_ONLY, ISAAC_PYTHON_PORT, et SHOWCASE_WORK_DIR. Conservez le domaine isolé par défaut à moins qu'il ne soit en conflit avec un autre déploiement ROS local. Appliquez le même domaine et paramètre localhost à Isaac Sim et Carter SIL. N'activez jamais le transport localhost-seul sans vérifier la découverte inter-processus entre le bridge Isaac Sim hôte et Carter SIL réseau hôte.

Acceptation

Une réussite de --demo demande que Mission Database rapporte la mission soumise COMPLETED, que le même robot retourne à IDLE sans erreurs, et que les poses Mission Database prouvent le mouvement. L'état robot, les logs, une fenêtre Isaac Sim visible, ou une seule capture d'écran ne suffisent pas.

N'exécutez pas docker compose down -v, ne supprimez conteneurs, n'élaguez l'état Docker, ou ne supprimez le répertoire de travail comme récupération automatique.