Détection et suivi du déploiement VSS 3D

Quand utiliser cette compétence

Déployez la stack MV3DT RT-CV-3D autonome depuis services/rtvi/rt-cv-3d/rt-cv-mv3dt. C'est le chemin par défaut pour les demandes MV3DT / RTVI-CV-3D / suivi multi-caméra.

Ne dérivez pas les services MV3DT du blueprint warehouse pour cette compétence. Utilisez vss-deploy-profile uniquement lorsque l'utilisateur demande explicitement warehouse MV3DT, le blueprint warehouse, un profil bp_wh*, des fichiers compose warehouse, ou la stack d'application warehouse combinée. Lors du routage d'une demande MV3DT warehouse explicite, énoncez également la limite : MV3DT générique utilise RT-CV-3D autonome, tandis que warehouse MV3DT utilise le déploiement warehouse/profil. Pour la détection ou le suivi 2D mono-caméra, utilisez plutôt les compétences de suivi 2D ou DeepStream.

Documentation publique : https://docs.nvidia.com/vss/latest/object-detection-tracking.html.

Exemples

Exemples de prompts opérationnels :

• « Déployez MV3DT sur mon dataset MP4 à quatre caméras calibré et sauvegardez la sortie. »
• « Déployez MV3DT sur le dataset exemple. »
• « Activez le suivi multi-caméra sur le dataset exemple 4-cam. »
• « Exécutez RTVI-CV-3D sur ces flux RTSP après calibrage. »
• « Déployez le suivi multi-cam ; s'il n'y a pas d'affichage, sauvegardez les vidéos. »
• « Utilisez un courtier MQTT externe et Kafka externe pour ce déploiement RT-CV-3D. »
• « Vérifiez le déploiement RT-CV-3D autonome et affichez les chemins de sortie. »
• « Arrêtez tout pour MV3DT autonome. »

Permissions de sortie

Limitez les permissions de sortie aux chemins runtime autonomes. Si les écritures de sortie échouent, signalez plutôt le propriétaire/mode du répertoire, l'utilisateur du conteneur et les logs pertinents au lieu d'assouplir largement les permissions.

Ce que cela déploie

Le fichier compose autonome est services/rtvi/rt-cv-3d/rt-cv-mv3dt/docker/compose.yml. Il déploie :

La stack autonome ne déploie pas VST, VIOS, NvStreamer, Elasticsearch, Kibana, Logstash, video-analytics-api, analytique comportementale, contrôleur SDR, configurateur warehouse, agents, LLM ou services VLM.

Règles fondamentales

• Utilisez par défaut les courtiers bundlés et COMPOSE_PROFILES=mosquitto,kafka pour les opérations Compose avec courtiers bundlés. Avant generate-configs.sh, stage-configs.sh ou lancement bundlé, exécutez le précontrôle de ressources bundlé : réutilisez les conteneurs autonomes existants de cette app sans réécrire les ports, rejetez les collisions de conteneurs de nom fixe étrangères, et pour un nouveau départ sélectionnez les ports Kafka, MQTT et DeepStream REST libres dans le docker/.env autonome. N'utilisez pas docker compose up -d full-stack comme chemin de lancement en mode fichier générique ; le mode fichier doit démarrer les services support, capturer les lignes de base Kafka, optionnellement prémarrer BEV, et seulement ensuite démarrer perception avec --no-deps.
• Pour les demandes de courtier externe explicites, collectez, exportez et validez MQTT_HOST, MQTT_PORT et KAFKA_BOOTSTRAP ; définissez USE_EXTERNAL_BROKERS=1 ; générez la config pub/sub avec MQTT_BROKERS="${MQTT_HOST}:${MQTT_PORT}" ./scripts/generate-configs.sh ; vérifiez que mdx-raw et mdx-bev existent déjà sur Kafka externe avec kafka-topics --describe borné ; utilisez le mode Compose courtier-externe sans profils bundlés ; et vérifiez les offsets Kafka contre le KAFKA_BOOTSTRAP externe. Les exécutions en mode fichier courtier-externe suivent toujours le même ordre à deux phases. Déléguez uniquement les variantes TLS/auth à la section custom-broker du README autonome.
• Exigez une entrée multi-caméra calibrée et synchronisée en temps. MV3DT nécessite au moins deux caméras ; les sources à 30 FPS doivent être synchronisées à environ une durée de frame près.
• Pour les fichiers enregistrés, utilisez INPUT_MODE=file ; chaque nom .mp4 doit correspondre à un id de capteur dans calibration.json et la camInfo générée. L'entrée fichier est une exécution de batch finie : dites à l'utilisateur d'avance que vss-rtvi-cv-mv3dt s'arrête après fin de flux et que les conteneurs support restants sont arrêtés après vérification réussie sauf si l'utilisateur demande de les conserver.
• Pour le dataset exemple / dataset exemple 4-cam, chargez references/sample-dataset.md. Utilisez le flux exemple autonome : app-data warehouse NGC pour modèles/vidéos, exemple de repo calibration.json et Top.png pour calibrage/carte BEV, transformations générées, INPUT_MODE=file, NUM_CAMS=4, courtiers bundlés, puis la décision d'affichage normal : décision affichage/sauvegarde : OSD live plus BEV fusionné live quand un affichage fonctionnel est trouvé et l'utilisateur n'a pas demandé à sauvegarder ; grille sauvegardée plus BEV fusionné sauvegardé quand sans tête ou demandé explicitement.
• Quand l'utilisateur fournit des chemins MP4, préservez-les comme entrées de déploiement. Utilisez leur répertoire comme VIDEO_DIR quand les noms de base correspondent déjà aux ids de capteurs ; sinon créez des symlinks générés nommés <sensor_id>.mp4 uniquement quand le mappage est explicite ou sans ambiguïté par count/ordre. Ne mutez pas les vidéos source.
• Pour RTSP live, utilisez INPUT_MODE=stream. L'enregistrement REST dynamique est le premier chemin ; les clés de flux doivent correspondre aux ids de capteurs de calibrage. Utilisez le bloc d'enregistrement REST direct dans references/configure-cameras.md pour que le JSON de readiness soit analysé indépendamment de l'espace blanc. Ne traitez pas STREAM_ADD_SUCCESS ou stream-count seul comme succès. Un déploiement RTSP live réussit seulement quand les sources attendues deviennent actives, chaque caméra a un FPS récent non-nul, et les offsets mdx-raw/mdx-bev augmentent.
• Quand l'utilisateur fournit des URLs RTSP, préservez-les comme entrées de déploiement et enregistrez-les après que le service compose en mode flux soit exécuté avec le bloc REST direct dans references/configure-cameras.md ; le bloc attend /api/v1/ready pour que ds-ready devienne YES, donc la ligne log ds-ready: YES est preuve diagnostique optionnelle. N'arrêtez pas en disant à l'utilisateur d'exécuter l'enregistrement manuellement. Demandez le mappage uniquement si les URLs nues ne peuvent pas être mises en correspondance avec les ids de capteurs de calibrage par count/ordre. Si l'enregistrement dynamique accepte les flux mais que les sources actives, FPS ou croissance Kafka restent zéro après vérification bornée, traitez l'ajout dynamique comme échoué et utilisez le fallback RTSP statique générique [source-list] dans references/configure-cameras.md avec les mêmes mappages sensor_id=rtsp://... fournis par l'utilisateur. Ne substituez pas l'exemple de calibrage ou les mappages de caméras exemple sauf si l'utilisateur a explicitement demandé le dataset exemple.
• Si le calibrage est manquant, transmettez à vss-generate-video-calibration et exécutez son précontrôle de plateforme AMC avant VIOS, capture, upload ou travail de calibrage. Si le précontrôle échoue, arrêtez et demandez à l'utilisateur de fournir les artefacts de calibrage existant/généré ou de choisir un hôte de calibrage x86_64 dGPU/NVENC supporté. Pour le calibrage RTSP, utilisez vss-manage-video-io-storage uniquement pour apporter ou vérifier le prérequis VIOS quand VIOS n'est pas déjà déployé/accessible ; AMC possède le calibrage et le câblage env VIOS_BASE_URL une fois VIOS disponible.
• N'utilisez pas VST pour la visualisation. Utilisez le chemin OSD autonome/save-video et les scripts visualiseur BEV.
• Exécutez toujours la sonde d'affichage réelle dans references/configure-cameras.md avant de choisir OSD=0 comme fallback sans tête ; n'inférez pas le mode sans tête seulement à partir de la présence GPU, de l'installation xdpyinfo ou d'un DISPLAY obsolète/manquant. Traitez le mode d'affichage comme deux fenêtres live par défaut : la grille de caméras OSD DeepStream et le visualiseur BEV fusionné séparé. Traitez save video, save output et fallback sans tête confirmé comme grille de perception sauvegardée plus BEV fusionné sauvegardé par défaut. Avant lancement, précontrôlez les outils hôte nécessaires pour la sortie sélectionnée : ffprobe pour vérification d'artefacts sauvegardés, et les dépendances Python/OpenCV/Kafka du visualiseur BEV quand la visualisation/enregistrement BEV est activé. Avant de promettre BEV, résolvez BEV_DATASET_PATH en un répertoire contenant à la fois map.png et transforms.yml ; si l'un manque, demandez l'asset BEV manquant ou signalez explicitement la sortie perception-grid-only.
• La vidéo BEV n'est pas émise par le conteneur perception. Elle est produite par le consommateur Kafka scripts/bev-visualizer.sh côté hôte séparé. Pour l'entrée fichier finie, gardez le processus BEV sous la même session/shell long-lived qui démarre la perception, attend l'EOS, vérifie les offsets/artefacts, finalise BEV et effectue le nettoyage ; ne démarrez pas BEV dans un appel outil court séparé et ne supposez pas que nohup ... & survivra au nettoyage de groupe de processus runner. Attendez l'affectation Kafka et vérifiez que le PID est encore vivant immédiatement avant la perception en mode fichier ou l'enregistrement de flux RTSP. Pour les exécutions live d'entrée fichier fini avec affichage, démarrez le BEV fusionné live avant la perception et, après l'EOS, dites à l'utilisateur d'appuyer sur q dans la fenêtre BEV ou arrêtez uniquement le PID BEV du run courant suivi via le flux de teardown sûr.

Workflow

Utilisez le tableau de sélection de workflow et les stages de run ci-dessous. Chargez uniquement les références nécessaires pour le chemin sélectionné de l'utilisateur pour entrée, courtier, visualisation, calibrage et vérification.

Sélection de workflow

Chargez les références minimales nécessaires pour la demande actuelle :

Stages de run

Suivez ces stages pour le travail de déploiement :

1. Résolvez RTCV3D_APP en services/rtvi/rt-cv-3d/rt-cv-mv3dt.
2. Identifiez le mode d'entrée : file pour les MP4 locaux ou stream pour RTSP.
3. Si l'utilisateur a demandé le dataset exemple ou le dataset exemple 4-cam, chargez d'abord references/sample-dataset.md. Résolvez/téléchargez app-data, définissez MODELS_DIR, VIDEO_DIR=<APP_DATA_DIR>/videos/warehouse-4cams-20mx20m-synthetic, CALIBRATION_JSON, BEV_DATASET_PATH, NUM_CAMS=4 et INPUT_MODE=file, puis continuez avec la validation des caméras et la décision affichage/sauvegarde normale avant de définir OSD, SAVE_VIDEO ou BEV_SAVE_VIDEO.
4. Validez ou obtenez calibration.json. Si manquant, transmettez à vss-generate-video-calibration par nom et ne dupliquez pas le workflow AMC inline. Incluez explicitement le chemin d'échec du précontrôle de plateforme AMC : arrêtez et demandez les artefacts de calibrage existant/généré ou un hôte de calibrage x86_64 dGPU/NVENC supporté. Après la fin d'AMC, récupérez le ZIP d'export MV3DT AMC, exportez calibration.json, validez le JSON en filtrant les capteurs où type == "camera" et exigez au moins deux IDs de caméra uniques non-vides et sûrs, puis staged les assets BEV avant de continuer. Pour la sortie sauvegardée ou la visualisation BEV, résolvez BEV_DATASET_PATH en un répertoire contenant à la fois map.png et transforms.yml avant le lancement.
5. Définissez les valeurs requises dans docker/.env : MODELS_DIR, NUM_CAMS, INPUT_MODE, VIDEO_DIR pour l'entrée fichier et les valeurs image/GPU optionnelles. Pour les chemins MP4 fournis, pointez VIDEO_DIR sur le répertoire source correspondant ou sur un répertoire de symlink généré avec un <sensor_id>.mp4 par caméra.
6. Initialisez le mode courtier avant la génération ou le staging de configs. Pour le mode bundlé, exécutez maintenant le précontrôle de ressources bundlé dans references/deploy-rtvi-cv-3d-stack.md pour que MQTT_PORT, KAFKA_PORT et KAFKA_BOOTSTRAP sélectionnés soient déjà dans docker/.env. Pour le mode externe, validez les endpoints du courtier et les topics requis avant le lancement.
7. Générez generated/camInfo/ et generated/pub_sub_info_config.yml depuis calibration.json avec le scripts/generate-configs.sh autonome, en utilisant l'endpoint MQTT sélectionné ; ne montez pas les répertoires de calibrage MV3DT warehouse.
8. Exécutez la sonde d'affichage concrète depuis references/configure-cameras.md avant le staging de configs ; elle doit tester le DISPLAY courant et les candidats de socket X découverts tels que :0/:1, exporter un DISPLAY fonctionnel quand trouvé, et imprimer RTCV3D_DISPLAY_AVAILABLE. Puis choisissez la visualisation :
   • Si un affichage fonctionnel est détecté et l'utilisateur n'a pas demandé à sauvegarder, staged avec OSD=1 SAVE_VIDEO=0, définissez BEV_SAVE_VIDEO=0 BEV_SOURCE=fused et utilisez la visualisation BEV fusionnée live quand les assets BEV sont présents.
   • Si aucun affichage n'est détecté, utilisez la sortie sauvegardée comme fallback par défaut : définissez SAVE_VIDEO=1 et sauvegardez le BEV fusionné après que BEV_DATASET_PATH se résolve avec les deux fichiers requis.
   • Si l'utilisateur a demandé à sauvegarder la sortie, définissez SAVE_VIDEO=1 même quand un affichage existe et sauvegardez aussi le BEV fusionné par défaut après que BEV_DATASET_PATH se résolve avec les deux fichiers requis.
   • Si l'utilisateur a demandé à la fois l'affichage live et la sortie sauvegardée, utilisez OSD=1 SAVE_VIDEO=1 et démarrez le BEV fusionné sauvegardé en parallèle.
9. Staged les configs DeepStream avec scripts/stage-configs.sh, puis assertez que generated/configs/ds-main-config-mv3dt.txt contient une msg-broker-conn-str Kafka correspondant à KAFKA_BOOTSTRAP sélectionné et RAW_TOPIC. Pour INPUT_MODE=file, assertez aussi que la config staged désactive le drop de latence live : [source-list] low-latency-mode=0, [source-attr-all] drop-on-latency=0 et [source-attr-all] latency=100000.
10. Précontrôlez la sortie/outillage et la capacité d'écriture du cache de modèles. Les constructions froides de moteurs TensorRT peuvent prendre 5-10 minutes et doivent pouvoir persister les moteurs sous les répertoires de modèles montés. Énoncez cet avertissement et le motif de remédiation ACL scopé dans le statut/rapport visible par l'utilisateur. Si un cache de modèles n'est pas inscriptible par le UID/GID du conteneur, arrêtez et demandez l'approbation avant d'appliquer une ACL à seulement le répertoire de modèles affecté, par exemple sudo setfacl -m u:<uid>:rwx -m d:u:<uid>:rwx <model-dir> ; n'utilisez pas large chmod 777 ou large chown récursif.
11. Pour chaque exécution INPUT_MODE=file, démarrez les courtiers sélectionnés et bev-fusion, attendez la readiness du courtier/topic-init/BEV Fusion, puis capturez les lignes de base Kafka avant de démarrer perception. Faites cela même quand la sortie sauvegardée ou la visualisation BEV n'est pas demandée.
12. Si le BEV sauvegardé est sélectionné/par défaut, ou si l'entrée fichier a besoin d'une visualisation BEV live/sauvegardée, utilisez le lancement à deux phases dans references/deploy-rtvi-cv-3d-stack.md : après la readiness support et les lignes de base fichier, démarrez le visualiseur/enregistreur BEV dans la même session/shell long-lived qui démarrera perception, attendez l'EOS, vérifiez les sorties et finalisez BEV. Attendez l'affectation du groupe de consommateurs Kafka, vérifiez que le PID de l'enregistreur est encore vivant, puis démarrez perception avec --no-deps. La sortie sauvegardée utilise BEV_SAVE_VIDEO=1 BEV_SOURCE=fused par défaut ; la sortie affichage-only utilise BEV_SAVE_VIDEO=0 BEV_SOURCE=fused pour que la fenêtre BEV soit live. Pour le mode stream sans exigence de prémarrage BEV, le lancement Compose full-stack est acceptable : bundlé utilise COMPOSE_PROFILES=mosquitto,kafka docker compose up -d ; externe utilise docker compose up -d. N'utilisez jamais full-stack docker compose up -d pour l'entrée fichier.
13. Pour l'entrée RTSP, après que le stream-mode compose soit exécuté, enregistrez les flux fournis avec le bloc REST direct dans references/configure-cameras.md, qui attend /api/v1/ready pour ds-ready=YES en utilisant l'analyse JSON. Utilisez des paires explicites <sensor_id>=<rtsp_url> quand fournies ; sinon mappez les URLs nues aux ids de capteurs de calibrage uniquement quand les counts et ordres sont clairs. Préservez le mappage final pour qu'il puisse aussi être utilisé pour le fallback static RTSP source-list si l'ajout REST dynamique ne produit pas les sources actives.
14. Pour RTSP, vérifiez la readiness REST, l'enregistrement exact du flux, les FPS non-nuls, la croissance des offsets mdx-raw/mdx-bev et les artefacts de visualisation demandés. Si l'enregistrement réussit mais que les sources actives/FPS/Kafka restent zéro, retuaged le même mappage RTSP comme [source-list] statique, redémarrez seulement la perception comme approprié pour le mode stream et réexécutez la même vérification. Pour l'entrée fichier, n'exigez pas ds-ready: YES ; traitez vss-rtvi-cv-mv3dt Exited (0) avec App run successful comme succès EOS, puis exigez que les offsets mdx-raw et mdx-bev soient plus grands que les lignes de base pré-run.
15. Pour les exécutions d'entrée fichier terminées, après vérification des sorties, arrêtez seulement les services support autonomes restants sauf si l'utilisateur a demandé de les garder en exécution pour inspection ou réutilisation. Préservez les configs générées, calibrage, vidéos et sorties.

Critères de succès

• generated/camInfo/ contient un .yml par capteur de caméra filtré et generated/configs/ existe.
• Les images runtime sont signalées depuis docker compose config --images ; la compétence n'infère pas les tags d'image de sa propre version.
• docker compose utilise services/rtvi/rt-cv-3d/rt-cv-mv3dt/docker/compose.yml.
• vss-rtvi-cv-bev-fusion devient healthy.
• Pour RTSP : REST /api/v1/ready signale ds-ready=YES, le count de flux enregistré égale NUM_CAMS, les IDs enregistrés correspondent exactement aux IDs camInfo générés sans doublons/extras, chaque source attendue a un FPS récent non-nul et les offsets mdx-raw et mdx-bev augmentent tandis que les flux sont actifs.
• Pour l'entrée fichier : vss-rtvi-cv-mv3dt peut finir comme Exited (0) après l'EOS et n'est réussi que quand les logs incluent App run successful et les deux offsets mdx-raw et mdx-bev dépassent les lignes de base pré-run.
• Si OSD live a été sélectionné, l'accès à l'affichage a été vérifié avant staging avec OSD=1 sans large xhost + et la visualisation en mode affichage inclut à la fois la fenêtre OSD de grille de caméras DeepStream et la fenêtre visualiseur BEV fusionné séparée quand les assets BEV sont présents.
• Si la sortie sauvegardée a été sélectionnée/par défaut, signalez le video-output/grid-view.mkv du run courant et les chemins d'artefact BEV sauvegardés avec taille non-vide, vérifications de timestamp de début de run, succès ffprobe et preuve log BEV courante incluant Video saved avec count de frame positif. Si BEV a été ignoré parce que les assets manquaient, signalez cela explicitement.
• Si la visualisation BEV live a été sélectionnée, signalez le PID/log visualiseur suivi, la preuve d'affectation du groupe de consommateurs Kafka et pour l'entrée fichier finie soit que l'utilisateur a fermé la fenêtre BEV avec q soit que le PID du run courant suivi a été arrêté sûrement après l'EOS.

Compétences associées

• vss-generate-video-calibration possède le déploiement AMC et le calibrage depuis des MP4 locaux ou des flux RTSP.
• vss-manage-video-io-storage est utilisé uniquement pour apporter ou vérifier VIOS quand le calibrage RTSP nécessite VIOS et qu'il n'est pas déjà déployé.
• vss-deploy-profile possède les déploiements blueprint warehouse full, incluant les demandes warehouse MV3DT explicites.