BEVFusion

BEVFusion pour la détection 3D multi-capteurs. Fusionne les nuages de points LiDAR et les images de caméra dans l'espace vue aérienne (BEV). Utilisé en conduite autonome pour une perception 3D robuste.

Définissez les chemins du backbone préentraîné pour le backbone image Swin.

Schémas Dataclass

Les schémas TAO Core générés sont packagés dans schemas/<action>.schema.json, avec schemas/manifest.json listant les actions disponibles. Chaque schéma généré émet également references/spec_template_<action>.yaml à partir du champ default du niveau supérieur du schéma. L'activation AutoML est déclarée au niveau du modèle dans references/skill_info.yaml via automl_enabled. L'AutoML exécutable nécessite toujours que schemas/train.schema.json et references/spec_template_train.yaml existent et soient valides. Utilisez le schéma train packagé pour automl_default_parameters, automl_disabled_parameters, les valeurs par défaut, les bornes min/max, les enums, les poids d'options, les conditions mathématiques, les dépendances et les paramètres populaires. Ne comptez pas sur ~/tao-core à l'exécution ; les mainteneurs régénèrent les schémas/templates avant de packager la skill bank.

Politique Train Action

Ce modèle est activé pour AutoML au niveau du modèle. Avant de traiter toute requête au stade train, lisez references/skill_info.yaml et résolvez l'override de run à partir soit d'une valeur automl_policy explicite, soit de la requête workflow de l'utilisateur. Traitez les phrases comme « turn off AutoML », « disable AutoML », « no HPO » ou « plain training » comme automl_policy: off pour cette run uniquement ; sinon, utilisez par défaut auto. Lorsque automl_policy: auto, automl_enabled: true, et que schemas/train.schema.json et references/spec_template_train.yaml sont packagés, routez l'action train par défaut via tao-skill-bank:tao-run-automl avec le skill_dir de ce modèle. Préservez les overrides workflow/application pour les datasets, specs, répertoires de sortie, paramètres GPU/platform, checkpoints parents et automl_policy. Utilisez l'entraînement direct du modèle uniquement quand automl_policy: off ou si le schéma/template train packagé est manquant ; en cas de schéma manquant, signalez que AutoML est activé mais non exécutable pour ce modèle jusqu'à la génération des schémas.

Les actions autres que train comme evaluate, inference, export et les flux deploy restent dans cette skill modèle. L'override automl_policy par run ne change pas les métadonnées du modèle.

Exigences d'entraînement

• Type de dataset : bevfusion
• Formats : default
• Métrique de monitoring : AP11

Exigences de dataset par action

Overrides Spec typiques

Les overrides de source de données sont obligatoires pour chaque action — l'agent DOIT construire les chemins de source de données à partir du tableau Exigences de dataset par action ci-dessus et les inclure dans spec_overrides.

S3_TRAIN = "s3://bucket/data/train"

train (sources de données obligatoires) :

{
    "train.num_epochs": 30,
    "train.checkpoint_interval": 10,
    "train.validation_interval": 10,
    "train.num_gpus": 1,
    "dataset.train_dataset": {"ann_file": f"{S3_TRAIN}/results/{dataset_convert_job_id}/kitti_person_infos_train.pkl"},
    "dataset.val_dataset": {"ann_file": f"{S3_TRAIN}/results/{dataset_convert_job_id}/kitti_person_infos_val.pkl"},
    "dataset.test_dataset": {"ann_file": f"{S3_TRAIN}/results/{dataset_convert_job_id}/kitti_person_infos_val.pkl"},
}

evaluate (sources de données obligatoires) :

{
    "dataset.test_dataset": {"ann_file": f"{S3_TRAIN}/results/{dataset_convert_job_id}/kitti_person_infos_val.pkl"},
}

inference (sources de données obligatoires) :

{
    "dataset.root_dir": f"{S3_TRAIN}",
    "dataset.test_dataset": {"ann_file": f"{S3_TRAIN}/results/{dataset_convert_job_id}/kitti_person_infos_val.pkl"},
}

Dataset d'évaluation

Optionnel. La split de validation est configurée via ann_file dans la config dataset.

Paramètres importants

• dataset.classes : Liste des classes de détection. Par défaut ["person"]. Doit correspondre aux catégories d'annotation.
• dataset.type : Type de dataset. Options : KittiPersonDataset, TAO3DSyntheticDataset, TAO3DDataset.
• dataset.root_dir : Répertoire racine du dataset de style KITTI.
• dataset.box_type_3d : Repère de coordonnées de boîte 3D. Options : lidar, camera. Par défaut lidar.
• train.optimizer.lr : Taux d'apprentissage. Par défaut 2e-4 (AdamW). Utilisez AmpOptimWrapper pour la précision mixte via optimizer.wrapper_type.
• input_modality : Dict contrôlant les modalités capteurs. Clés : use_lidar (True), use_camera (True), use_radar (False), use_map (False).
• model.img_backbone : Image backbone. Par défaut mmdet.SwinTransformer (Swin-Tiny). embed_dims=96, depths=[2,2,6,2].
• model.view_transform.type : Transformation de vue pour la projection BEV. Options : DepthLSSTransform, LSSTransform. Par défaut DepthLSSTransform.
• model.point_cloud_range : Étendue spatiale du LiDAR. Par défaut [0,-40,-3,70.4,40,1].
• model.voxel_size : Dimensions des voxels. Par défaut [0.05, 0.05, 0.1].
• dataset.train_dataset.batch_size : Batch size par GPU. Par défaut 4.

Multi-GPU / Multi-nœud

Méthode de lancement : torchrun (LIGHTNING_EXCLUDED_NETWORK). Le point d'entrée exécute torchrun --nnodes=N --nproc-per-node=M train.py, PAS un simple python.

• CUDA_VISIBLE_DEVICES est explicitement défini à partir de TAO_VISIBLE_DEVICES
• BEVFusion utilise l'entraînement distribué basé sur mmdet3d, pas Lightning DDP
• NODE_RANK est copié vers RANK si RANK n'est pas défini

Variables d'environnement multi-nœud (définies par l'orchestrateur) :

Matériel

Minimum 2 GPU, 4 GPU recommandés. 24 GB+ (A100 recommandé) VRAM par GPU. BEVFusion consomme beaucoup de mémoire du fait de la fusion multi-capteurs. Les GPUs A100 sont fortement recommandés. L'entraînement multi-GPU est attendu.

Motifs d'erreur

dataset_convert obligatoire : Exécutez dataset_convert avant l'entraînement pour produire les fichiers pickle info.

Données de modalité manquantes : Assurez-vous que les images de caméra et les nuages de points LiDAR sont tous deux présents si vous utilisez la fusion multi-modale.

Numérotation des epochs : Les numéros d'epoch des checkpoints BEVFusion peuvent ne pas suivre le format standard avec zéro rembourrage.

Param Spec / Inférence du modèle parent

Les mappages d'inférence spécifiques au modèle doivent se trouver dans ce fichier MD, pas dans config.json. Les runners générés doivent lire cette section et appliquer les mappages avec les SDK helpers avant create_job(). Cela reflète le flux infer_params.py des anciens microservices.

Mappages d'inférence depuis bevfusion.config.json de TAO Core :

Pour parent_model ou parent_model_folder, passez l'ID du job enfant train/export/AutoML en amont comme parent_job_id. Le SDK liste le dossier de résultats parent, filtre les artefacts de checkpoint et retourne le fichier ou dossier modèle sélectionné. N'ajoutez pas ces mappages à config.json et ne patchifiez pas les scripts runners générés pour deviner les chemins de checkpoint.