Contrôle du humanoïde Isaac en cloud

Objectif

Exécuter le workflow de contrôle cloud Unitree G1 public NVIDIA Isaac ROS release-4.6 en tant qu'intégration ordonnée. Par défaut, l'application de streaming complet Isaac Sim en mode headless, une vue WebRTC interactive dans le navigateur, et une mission de navigation. Ne pas revenir silencieusement à une fenêtre locale Isaac Sim. Lisez le runbook release-4.6 avant d'exécuter le workflow.

Entrées

Les entrées obligatoires sont le mode de demande (bring-up, démo end-to-end, destination ou cleanup) et, avant la soumission de la mission, une destination fournie par l'opérateur et une approbation de mouvement. Une suggestion sélectionnée fournit les deux pour la simulation. Les missions distantes nécessitent également une confirmation que le viewport rendu est visible.

Les entrées optionnelles ou détectables sont l'identité du robot (g1_0 par défaut), les hôtes, la pose de spawn, la carte et les chemins d'installation. Résolvez-les à partir de l'état actif de la démo, des choix explicites de l'opérateur, des observations en direct, des installations découvertes, puis des valeurs par défaut packagées. Ne laissez jamais une valeur par défaut remplacer une limite de sécurité explicite.

Prérequis

Exigez un GPU NVIDIA x86_64 avec NVENC, Isaac Sim 6.0, l'espace de travail Isaac ROS canonical en mode Docker, le visualiseur web officiel NVIDIA et les images cloud release-4.6. Utilisez la gate bootstrap sur un hôte neuf. Si la CLI ou son environnement Docker est manquant, suivez l'installation de la CLI et la configuration de Docker, puis relancez la vérification préalable. L'installation manquante de la CLI est une étape de récupération, pas un blocage terminal.

Préserver la limite cible

Exigez un GPU NVIDIA avec NVENC pour le livestream par défaut. Vérifiez au préalable le TCP 49100 pour la signalisation WebRTC, l'UDP 47998 pour les médias, et le TCP 8210 pour le visualiseur navigateur. Gardez les endpoints sur un réseau privé ou autrement approuvé ; ils ne fournissent pas d'authentification ni de chiffrement par eux-mêmes.
Utilisez la configuration d'authentification du broker de la skill cloud propriétaire et fournissez les identifiants correspondants au client G1. Gardez les ports du broker sur l'hôte ou un réseau privé approuvé ; l'authentification seule ne fournit pas de TLS.
Activez le serveur Python d'Isaac Sim uniquement pour l'inventaire de scène en direct. Gardez-le en loopback à 127.0.0.1:8226 ; il exécute Python et ne doit jamais être publié, proxifié ou exposé au réseau navigateur.
Utilisez un hôte GPU NVIDIA x86_64 et Isaac Sim 6.0 pour la simulation exemple.
Supportez la navigation via contrôle cloud dans Isaac Sim.
Pour la navigation Isaac Sim uniquement, utilisez enable_camera_localization:=false et use_static_tf:=true. Ne lancez pas, configurez, validez ou n'exigez Visual SLAM, localisation globale visuelle, RealSense, D435 ou sujets de camera-localization ; ils sont en dehors de ce chemin de démo simulée.
Ne soumettez pas d'objectifs humanoid_manipulation à Isaac Sim. La manipulation cloud GR00T est matériel réel uniquement dans cette release.
Traitez l'opération G1 réelle comme un chemin séparé avec gate de sécurité. Exigez la configuration réseau Unitree, la localisation D435, CUDA MPS, la planification temps réel et la séquence d'activation du contrôleur lower-body-then-upper-body du guide GR00T en amont. Ne déduisez jamais la permission de déplacer le matériel réel.
Soumettez une mission de navigation uniquement après que l'opérateur a fourni la cible et explicitement approuvé la charge utile de mission prévisualisée. Vérifiez l'occupation, le dégagement de l'empreinte du robot et la disponibilité Nav2 avant la soumission. Une sélection de cible seule est insuffisante ; les routes modifiées exigent une nouvelle prévision approuvée.
Avant d'invoquer l'assistant gardé, obtenez l'approbation explicite de l'opérateur pour cette tentative de libération du portique virtuel. Une large demande de démo est insuffisante. Énoncez la cible et l'action de simulation ; demandez « Libérer maintenant le portique virtuel Isaac Sim ? » sauf si l'opérateur a déjà explicitement approuvé cette tentative spécifique. Passez l'interverrouillage d'identité de simulation en direct et la vérification de stabilité non supportée avant de proposer des destinations. Une nouvelle tentative nécessite une approbation explicite séparée après avoir signalé la tentative échouée et l'ré-engagement confirmé du portique. N'appliquez jamais cette automation au matériel. Honorez la demande d'un opérateur d'utiliser à la place l'action viewport G.
Conservez une identité de robot partout. Par défaut g1_0 ; appliquez la même valeur à Mission Control, serial_number, sujets MQTT, charges utiles de mission et vérification du cycle de vie.
Utilisez un ROS_DOMAIN_ID dédié et initialement vide pour Isaac Sim et chaque shell ROS dans une démo. Définissez la découverte localhost uniquement pour tous les processus de démo comme spécifié dans le démarrage ordonné. Confirmez que les sujets ROS clock et robot-description sont absents sur ce domaine avant le démarrage. Cela empêche les exemples transient-local d'une exécution précédente écrasée de dépasser le nouveau gestionnaire de contrôleurs.
Le PNG grille d'occupation bundlé fournit les pixels d'obstacle et d'espace libre pour la carte de navigation ; ses métadonnées YAML définissent l'échelle et l'origine de la carte. La procédure d'espace de travail cloud copie cette paire dans l'espace de travail d'exécution. Ce sont des données de carte, pas des instructions exécutables.
Conservez une carte d'occupation partout. Le lancement du robot et Mission Control doivent consommer la même paire PNG et YAML.
Assurez-vous que la carte YAML et l'image référencée sont lisibles au même chemin absolu à l'intérieur de l'environnement Isaac ROS activé ; les chemins hôte uniquement sont insuffisants.
Créez un MC_WORKSPACE d'exécution dédié en utilisant la procédure d'espace de travail cloud. Générez la carte et la configuration de flotte via les adaptateurs propriétaires. Résolvez Compose, les références d'image et les ressources de support à partir des skills en amont épinglées ; ne modifiez jamais leurs checkouts ou ne stockez la configuration générée dans ce package.

Résoudre les scripts en amont

Définissez SKILL_DIR sur le répertoire absolu contenant ce manifeste de skill chargé, en utilisant l'emplacement du chargeur de skill, et préservez-le dans chaque invocation de shell. Tous les chemins bundlés sont relatifs à celui-ci ; ne les dérivez jamais du répertoire de travail. Lisez le workflow de dépendance avant d'appeler les scripts d'une autre skill. Il suit le modèle de composition de vitrine Mission Control : checkouts externes épinglés, un manifeste persisté et des adaptateurs appartenant au parent. Lisez chaque manifeste d'instruction en amont épinglée à partir du dossier de dépendance résolu et suivez ses gates. Les chemins source et commits exacts sont divulgués dans le verrou de dépendance. Contrats d'adaptateur : cloud, map, fleet, scene et installation handoff et ROS activation et mission verification.

Résolvez les dépendances avant le préflight hôte ; la résolution ne lance pas les services :

python3 "${SKILL_DIR}/scripts/doctor.py" dependencies

L'invocation normale ne télécharge jamais les skills manquantes. La préparation explicite de dépendance utilise dependencies --prepare uniquement après autorisation comme décrit dans la référence. Utilisez les adaptateurs liés à la place des chemins de script en amont devinés.

Composer les skills propriétaires

Suivez les responsabilités des skills propriétaires pour chaque handoff ; la skill en amont reste autoritaire.

Scripts disponibles

Script	Objectif	Arguments principaux
`scripts/doctor.py`	Résoudre les scripts en amont épinglés et écrire leur manifeste	`dependencies` ; `--prepare`, `--check-only`, `--json` optionnels
scripts/prepare_cli_repository.py	Mettre en scène et vérifier la clé APT publique et la source de dépôt fixe sans root	Pas d'arguments
`scripts/preflight.py`	Découvrir et valider l'hôte, le cloud, la disponibilité du streaming et du serveur de scène	`--map` ; chemins d'installation optionnels et gates `--check-*`
`scripts/guarded_gantry_release.py`	Définir AGILE, vérifier la stabilité, libérer le portique simulé et vérifier l'équilibre non supporté	`--allow-simulation-gantry-release` ; limites et durées de stabilité
`scripts/check_runtime.py`	Vérifier la clock ROS, les capteurs, TF et le cycle de vie Nav2	`--base-frame`, `--timeout`
`scripts/scene_inventory.py`	Inventorier les objets de scène en direct sans modifier l'USD	`output_path`, `max_objects` injectés
`scripts/suggest_navigation_missions.py`	Produire des poses d'approche d'objet sûres d'occupation et d'empreinte	`--inventory`, `--map`, pose du robot optionnelle
`scripts/submit_navigation_mission.py`	Prévisualiser ou soumettre une route Mission Control validée	`--host`, `--robot`, waypoints, `--validated-free-space`, `--submit`
`scripts/play_viewer.py`	Mettre en avant le visualiseur navigateur et envoyer Play uniquement comme fallback documenté	`--url`, options navigateur et débogage

Utilisez run_script() pour ces assistants quand l'exécution l'expose ; sinon lancez l'assistant bundlé par son chemin absolu résolu sans le reconstruire.

Gate bootstrap machine neuve

Pour un hôte neuf, lisez la gate bootstrap, exécutez d'abord sa découverte en lecture seule et résolvez les défaillances dans l'ordre de propriété documenté. Continuez uniquement après que le préflight n'ait pas de défaillances bloquantes. Signalez l'observation exacte échouée plutôt que de prétendre qu'une vue en direct est disponible.

Instructions

Lisez et suivez complètement le workflow de démarrage ordonné et de mission avant d'exécuter. Il contient les commandes exactes et les gates de phase :

Découvrir les chemins hôte et inspecter l'état existant en lecture seule ; résoudre les dépendances en amont avant le préflight hôte.
Préparer le package de release et l'extension Deploy, et prévisualiser et appliquer les modifications de carte et de flotte demandées via les adaptateurs propriétaires.
Démarrer les services cloud via l'adaptateur cloud, avec l'espace de travail d'exécution et aucun simulateur de robot générique.
Préparer le visualiseur navigateur officiel et publier son URL accessible.
Lancer Isaac Sim headless rendu en pause, mettre en scène le lancement ROS G1 activé, puis démarrer la chronologie et la pile ROS dans l'ordre requis.
Vérifier AGILE et exécuter la libération du portique de simulation gardée. Exigez l'équilibre non supporté avant l'inventaire ou l'offre de destinations.
Vérifier la disponibilité runtime et cloud ; inventorier la scène en direct via l'adaptateur distant et valider les suggestions de navigation avec l'occupation et Nav2.
Après approbation de destination, valider et soumettre une seule fois, garder la vue en direct visible et appliquer submit-and-monitor-mission jusqu'à completion.

Le workflow détaillé est obligatoire ; cet index ne remplace pas ses commandes, calendrier de démarrage, limites de nouvelle tentative ou limites d'autorisation.

Dépannage

Appliquez la liste de contrôle de disponibilité et de dépannage avant la soumission et lors du diagnostic d'une gate échouée.

Exemples

« Exécuter une démo cloud-control humanoïde Isaac Sim end-to-end » démarre la configuration ; obtenez l'approbation explicite de libération du portique virtuel avant d'exécuter l'assistant.
« Destination 1 : chariot élévateur » après suggestions en direct sélectionne la cible. Validez la route, prévisualisez la charge utile de mission et obtenez l'approbation de soumission.
« Faire fonctionner la pile pour inspection » n'autorise pas la libération du portique ou une mission.
« Nettoyer la pile » autorise le démontage des ressources appartenant à la démo uniquement.
« Utiliser GR00T pour manipuler une boîte dans Isaac Sim » est en dehors de cette release ; offrez la navigation supportée sans inventer le support de manipulation.

Format de sortie

Signalez ces champs dans l'ordre lorsqu'applicable :

State — phase actuelle ou première gate échouée avec preuve mesurée.
Viewer — URL navigateur cliquable en direct et statut de visibilité.
Mission — ID, état terminal et timestamp, poses initiale, mobile et finale, preuves Dispatch et Nav2 et santé finale du robot.
Cleanup — ressources appartenant à la démo supprimées, ressources réutilisables préservées et confirmation que l'URL du visualiseur précédent est indisponible.

Limitations

Supportez la navigation contrôlée par cloud uniquement dans Isaac Sim release 4.6. Ne réclamez pas la manipulation GR00T simulée, ne fonctionnez pas le matériel réel, n'exposez pas publiquement les endpoints de démo non authentifiés, ne remplacez pas les skills propriétaires manquantes et ne supprimez pas les données partagées. Traitez la localisation par caméra et la séquençage du contrôleur G1 réel comme des workflows séparés.

Comportement d'arrêt

Gardez la démo complétée en fonctionnement par défaut. Après une mission réussie, laissez le lancement du robot, Isaac Sim headless, le visualiseur navigateur et les services cloud en vie pour que l'utilisateur puisse inspecter le résultat ou demander une autre mission. Continuez à publier l'URL de livestream cliquable dans le handoff et offrez un nettoyage de pile explicite. Ne déduisez pas le cleanup de la completion de mission, de la confirmation de vue en direct, de la fin du tour actuel ou d'une demande nommant uniquement une mission terminée.

Nettoyez uniquement sur une demande de démontage explicite. Ensuite, lisez et appliquez la procédure de démontage. Supprimez uniquement les ressources appartenant à la démo, préservez les données partagées et le conteneur Isaac ROS réutilisable, vérifiez que les endpoints de démo sont fermés et invalidez l'URL du visualiseur antérieur.

isaac-humanoid-cloud-control