# Wall-OSS-0.5 Wall-OSS-0.5 est un modèle vision-langage-action de 4B issu de [XSquare Robot](https://x2robot.com/en/research/68bc2cde8497d7f238dde690). Il combine un socle vision-langage Qwen2.5-VL avec un expert d'action en appariement de flux continu. LeRobot fournit Wall-OSS-0.5 via le type de politique `wall_oss_05` et le point de contrôle [`lerobot/wall-oss-0.5`](https://huggingface.co/lerobot/wall-oss-0.5). `wall_oss_05` et la politique existante `wall_x` ciblent des versions WALL différentes. Utilisez `wall_oss_05` avec le checkpoint Wall-OSS-0.5. ## Aperçu du modèle Wall-OSS-0.5 conditionne la génération d’actions sur les observations de la caméra, l’état du robot et une tâche en langage naturel. La politique prédit un bloc d’actions continues par appariement de flux. Son expert vision-langage peut également générer du texte pour la légende, la question-réponse visuelle, l’ancrage et les sous-tâches linguistiques. Le modèle publié utilise : - une représentation canonique de l'état et de l'action de dimension 26 ; - chunks d'actions de 32 étapes ; - normalisation par plage q01/q99 ; - un échantillonneur de flux en 10 étapes ; - Qwen2.5-VL pour les entrées visuelles et linguistiques. Le point de contrôle de base est destiné à l'ajustement fin sur un jeu de données cible spécifique à un robot et à une tâche avant le déploiement. ### Ce que couvre l'intégration LeRobot - Configuration standard `policy.type=wall_oss_05` et chargement du point de contrôle du Hub. - Traitement natif de la vision et du langage pour Qwen2.5-VL et experts d’action Wall. - Entraînement de flux à prédiction x continue et échantillonnage d'Euler en 10 étapes. - Ajustement fin de l'entropie croisée de texte et de l'ajustement fin conjoint texte/action pilotés par des recettes. - Génération de texte native pour le VQA, le grounding, les légendes et les sous-tâches linguistiques. - Génération de texte directe via le déroulement interactif de LeRobot. - Entrées d'état et d'action canoniques 26D à l'aide des processeurs q01/q99 de LeRobot. - Fine-tuning avec `lerobot-train` et inférence via les API de politique standard. ## Prérequis d'installation Wall-OSS-0.5 nécessite un GPU NVIDIA avec CUDA. Installez LeRobot avec les dépendances de la politique : ```bash pip install "lerobot[wall_oss_05]" ``` Pour un dépôt source de LeRobot : ```bash uv sync --extra wall_oss_05 ``` La politique est implémentée nativement dans LeRobot. Sa seule dépendance spécifique à la politique est Transformers ; aucun dépôt Wall-X séparé n'est requis. Le traitement basé sur des recettes nécessite également l'extension dataset. Pour les requêtes en langage ou l'entraînement, installez `uv sync --extra wall_oss_05 --extra training` (l'entraînement inclut le support du dataset). Définissez `--policy.recipe=null` pour un traitement limité aux actions, sans l'extension dataset. ## Points de contrôle | Variante | Point de contrôle LeRobot | Usage prévu | | ------- | --------------------------------------------------------------------- | ---------------------------------------- | | Base 4B | [`lerobot/wall-oss-0.5`](https://huggingface.co/lerobot/wall-oss-0.5) | Fine-tuning et déploiement canoniques 26D | Le point de contrôle inclut la configuration de la politique, le processeur et le tokeniseur Qwen, les poids du modèle, les pré/post-processeurs LeRobot enregistrés, les statistiques de normalisation et les métadonnées de conversion. Il s'agit d'un point de contrôle de base : effectuez un fine-tuning sur le robot et la tâche cibles avant de signaler les résultats au niveau de la tâche. ## Utilisation Sélectionnez la politique avec : ```bash --policy.type=wall_oss_05 ``` Initialiser à partir du point de contrôle LeRobot avec : ```bash --policy.path=lerobot/wall-oss-0.5 ``` Utilisez `--policy.path=your-org/your-finetuned-checkpoint` lors de l'évaluation ou du déploiement d'un point de contrôle LeRobot enregistré. ### Texte et VQA Wall-OSS-0.5 utilise le contrat de texte de politique partagé. L’exécute fournit `query_kind` et `query_text`, puis exécute le processeur d’entrée de politique standard : ```python request = { **observation, "query_kind": "vqa", "query_text": "Which object is closest to the right gripper?", } processed_batch = preprocessor(request) answer = policy.generate_text(processed_batch) ``` `vqa` conserve la question de l'appelant. `next_subtask` applique la recette détenue par `WallOSS05Config`. La politique hérite de `generate_text(processed_batch)` et redéfinit `supports_text_generation` et `generate_text`. La génération utilise la tête de vocabulaire Qwen liée du point de contrôle ainsi que l'expert vision-langage ; elle n'appelle pas de VLM distinct. Le runtime de langage peut générer une sous-tâche puis conditionner la prédiction d’action de Wall sur celle-ci : ```bash lerobot-rollout \ --policy.path=your-org/your-finetuned-wall-oss-0.5 \ --policy.device=cuda \ --task="clear the table" \ --interactive=true ``` Après `/start`, utilisez `/vqa `, `/autosteer ` ou `/subtask `. Wall conserve des capacités utiles de VQA incarnée et d'ancrage, mais il est spécialisé pour les observations robotiques et n'est pas destiné à remplacer un VLM à usage général. ## Exigences en matière de données Wall-OSS-0.5 fonctionne en interne avec une disposition canonique d'état et d'action de 26D. Les caractéristiques d'état et d'action plus étroites sont normalisées avec les statistiques natives de leur jeu de données, puis complétées par des zéros jusqu'à 26D pour le modèle. Les dimensions d'action remplies sont exclues de la perte d'entraînement. Les sorties sont rognées à la largeur d'action du jeu de données avant la dénormalisation : un état de 8D avec des actions de 7D renvoie des actions de 7D. `postprocess_action_dim` peut appliquer une rognage supplémentaire de la sortie. Le remplissage ne remappe pas les coordonnées articulaires ni les conventions de contrôleur ; fournissez des valeurs compatibles. Configurez les entrées d’images avec `camera_key_mapping`. La correspondance associe chaque fonction d’image LeRobot à un emplacement de caméra Wall. Le point de contrôle par défaut utilise `face_view` et `right_wrist_view`. La chaîne de caractères de la tâche du jeu de données est transmise à la politique en tant qu'instruction de langage. Utilisez des descriptions de tâches cohérentes lors de l'enregistrement, de l'entraînement et de l'évaluation. La normalisation de l'état et de l'action q01/q99 est gérée par le préprocesseur et le postprocesseur LeRobot enregistrés. L'inférence restaure les statistiques enregistrées avec le point de contrôle. Lors de l'ajustement fin avec `lerobot-train`, les statistiques du jeu de données d'entraînement remplacent les statistiques du processeur pré-entraîné et sont enregistrées avec le nouveau point de contrôle. Le point de contrôle publié utilise le dictionnaire d'état natif de la politique LeRobot et le format actuel des pré/postprocesseurs. Les poids sont chargés et enregistrés via le code de persistance de la politique partagé, y compris les regroupements distribués et la porte d'écriture du processus principal. La configuration conserve une référence stable à l'actif du tokeniseur et peut être chargée depuis n'importe quel répertoire de travail. ## Entraînement Effectuez le fine-tuning du point de contrôle de base avec la commande standard d'entraînement LeRobot : ### Exemple de commande d'entraînement ```bash lerobot-train \ --dataset.repo_id=your-org/your-dataset \ --policy.path=lerobot/wall-oss-0.5 \ --policy.repo_id=your-org/wall-oss-0.5-your-task \ --output_dir=outputs/train/wall_oss_05 \ --job_name=wall_oss_05_finetune \ --policy.device=cuda \ --batch_size=1 \ --steps=20000 ``` Commencez par une taille de lot (batch size) réduite, car Wall-OSS-0.5 est un modèle de 4 milliards de paramètres. Augmentez-la en fonction de la mémoire GPU disponible, ou utilisez l'accumulation de gradients via votre configuration d'entraînement distribué. Pour les jeux de données avec des noms de caméras différents, mappez leurs clés de fonctionnalités vers les emplacements de caméras Wall. Par exemple, ajoutez l'option suivante pour `top` et `wrist` : ```bash --policy.camera_key_mapping='{"observation.images.top":"face_view","observation.images.wrist":"right_wrist_view"}' ``` Le fine-tuning détermine les formes des caméras et les largeurs d’état/action à partir du jeu de données, y compris lors du chargement du point de contrôle de base avec `--policy.path`. ### Entraîner avec des annotations linguistiques La recette associée à `WallOSS05Config` utilise par défaut les colonnes de langage optionnelles de LeRobot. Sa recette de sous-tâche articulaire supervise la réponse de l’assistant et le bloc d’actions continues dans une seule séquence causale : ```bash lerobot-train \ --dataset.repo_id=your-org/your-language-annotated-dataset \ --policy.path=lerobot/wall-oss-0.5 \ --policy.use_language_recipe=true \ --policy.text_loss_weight=0.1 \ --policy.flow_loss_weight=1.0 \ --policy.device=cuda \ --batch_size=1 \ --steps=20000 ``` Les flux de recettes déterminent quels objectifs sont exécutés pour chaque échantillon : - un tour d'assistant ciblé reçoit une entropie croisée de texte de jeton suivant ; - un tour `low_level` reçoit une supervision continue du flux-action ; et - Une recette `low_level` avec un tour d'assistant ciblé reçoit les deux pertes, les jetons d'action portant attention sur le texte supervisé. Une recette `low_level` avec un tour d'assistant ciblé reçoit les deux pertes, les jetons d'action portant attention sur le texte supervisé. Seule la charge utile de l’assistant visée et son jeton `<|im_end|>` sont utilisés comme étiquettes de langue. Les invites utilisateur, le bourrage, les images, la proprioception et les jetons d’action continue et de requête sont masqués de l’entropie croisée du texte. Les lignes sans annotations conservent l’invite et la perte d’action uniquement d’origine. Définissez `use_language_recipe=false` pour désactiver le rendu des annotations, ou `recipe=null` pour désactiver les deux rendus de recette. Un `recipe_path` explicite remplace la recette intégrée. Un fine-tuning neuf reconstruit les processeurs à partir de cette recette et des statistiques d’entraînement ; l’entraînement repris et le rollout restaurent les processeurs et les statistiques enregistrés dans le point de contrôle. Consultez [Colonnes de langue et recettes](./language_and_recipes) pour le schéma d’annotation et la structure des recettes. `recipe_path` peut pointer vers un fichier YAML externe explicite ; LeRobot ne fournit pas de fichiers de recette par défaut partagés. ## Paramètres de configuration clés | Paramètre | Par défaut | Description | | ------------------------- | -------------------------- | -------------------------------------------------------------- | | `pretrained_name_or_path` | `lerobot/wall-oss-0.5` | Source des actifs du tokeniseur et du processeur d'images | | `tokenizer_revision` | `None` | Épinglage facultatif du tokenizer de base, distinct de la révision des poids | | `chunk_size` | `32` | Nombre d'actions prédites par bloc | | `n_action_steps` | `32` | Nombre d'actions prédites exécutées avant la replanification | | `camera_key_mapping` | Vues de face et du poignet droit | Associe les clés de fonctionnalités d’image aux emplacements de caméra du modèle | | `use_language_recipe` | `true` | Active la recette stockée dans la configuration de la politique | | `recipe_path` | `None` | Remplacement explicite facultatif de la recette externe | | `text_loss_weight` | `0.1` | Poids pour l'entropie croisée des jetons d'assistant supervisés | | `flow_loss_weight` | `1.0` | Poids pour la perte d'action-flux continue | | `tokenizer_max_length` | `1000` | Longueur maximale de la séquence de jetons conjoints vision-langage-action | | `device` | auto | Utilisez `cuda` pour Wall-OSS-0.5 | ## Évaluation et inférence Utilisez un point de contrôle affiné avec les workflows standard d’évaluation LeRobot ou de déploiement sur robot en passant son dépôt Hub ou son répertoire local en tant que chemin de la politique. Wall-OSS-0.5 génère des segments d’actions continus avec son échantillonneur de flux. La politique actuelle prend en charge la branche de flux continue ; la branche d’actions autorégressive n’est pas exposée. Chaque bloc encode ses images de caméra et préremplit le préfixe observation/texte une seule fois. Les dix étapes d’Euler réutilisent les clés et valeurs du préfixe et décodent uniquement les jetons d’action. Le cache est reconstruit pour chaque nouvelle observation. Pour un simulateur pris en charge, fournissez le point de contrôle ajusté et les options spécifiques à l’environnement via `lerobot-eval` : ```bash lerobot-eval \ --policy.path=your-org/your-finetuned-wall-oss-0.5 \ --policy.device=cuda \ --env.type= \ --env.task= \ --eval.batch_size=1 \ --eval.n_episodes=10 ``` Ne pas évaluer le point de contrôle de base comme s'il s'agissait d'une politique spécifique à une tâche. La représentation canonique, les statistiques de normalisation et la distribution des tâches doivent correspondre à celles du point de contrôle après fine-tuning. ## Références - [Page du projet Wall-OSS-0.5](https://x2robot.com/en/research/68bc2cde8497d7f238dde690) - [Point de contrôle Wall-OSS-0.5 LeRobot](https://huggingface.co/lerobot/wall-oss-0.5) ## Licence Wall-OSS-0.5 et Wall-X sont publiés sous licence Apache 2.0.