LeRobot documentation

Wall-OSS-0.5

Hugging Face's logo
Join the Hugging Face community

and get access to the augmented documentation experience

to get started

Wall-OSS-0.5

Wall-OSS-0.5 est un modèle vision-langage-action de 4B issu de XSquare Robot. Il combine un socle vision-langage Qwen2.5-VL avec un expert d'action par correspondance de flux continue.

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.

wall_oss_05 et la politique existante wall_x ciblent des versions différentes de WALL. 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 :

pip install "lerobot[wall_oss_05]"

Pour un dépôt source de LeRobot :

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

VariantePoint de contrôle LeRobotUsage prévu
Base 4Blerobot/wall-oss-0.5Fine-tuning et déploiement canoniques 26D

Le checkpoint contient la configuration de la politique, le processeur et le tokenizer Qwen, les poids du modèle, les pré/postprocesseurs LeRobot enregistrés, les statistiques de normalisation et les métadonnées de conversion. Il s'agit d'un checkpoint de base : effectuez un fine-tuning sur le robot et la tâche cibles avant de rapporter des résultats au niveau de la tâche.

Utilisation

Sélectionnez la politique avec :

--policy.type=wall_oss_05

Initialiser à partir du point de contrôle LeRobot avec :

--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 :

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 réécrit supports_text_generation et generate_text. La génération utilise la tête de vocabulaire Qwen liée du point de contrôle et l’expert vision-langage ; elle n’appelle pas de VLM séparé.

Le runtime de langage peut générer une sous-tâche puis conditionner la prédiction d’action de Wall sur celle-ci :

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 <question>, /autosteer <goal> ou /subtask <text>.

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

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 :

--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 conjointe supervise la réponse de l’assistant et le bloc d’actions continues dans une seule séquence causale :

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 étant attentifs au 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-continua et de requête d’action 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 nouvel affinement reconstruit les processeurs à partir de cette recette et des statistiques d’entraînement ; l’entraînement repris et le déroulement restaurent les processeurs et les statistiques enregistrés dans le point de contrôle.

Consultez Colonnes de langue et recettes 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ètrePar défautDescription
pretrained_name_or_pathlerobot/wall-oss-0.5Source des actifs du tokeniseur et du processeur d'images
tokenizer_revisionNoneÉpinglage facultatif du tokenizer de base, distinct de la révision des poids
chunk_size32Nombre d'actions prédites par bloc
n_action_steps32Nombre d'actions prédites exécutées avant la replanification
camera_key_mappingVues de face et du poignet droitAssocie les clés de fonctionnalités d’image aux emplacements de caméra du modèle
use_language_recipetrueActive la recette stockée dans la configuration de la politique
recipe_pathNoneRemplacement explicite facultatif de la recette externe
text_loss_weight0.1Poids pour l'entropie croisée des jetons d'assistant supervisés
flow_loss_weight1.0Poids pour la perte d'action-flux continue
tokenizer_max_length1000Longueur maximale de la séquence de jetons conjoints vision-langage-action
deviceautoUtilisez 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éroulement 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 ne décodent que 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 :

lerobot-eval \
  --policy.path=your-org/your-finetuned-wall-oss-0.5 \
  --policy.device=cuda \
  --env.type=<environment> \
  --env.task=<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 au point de contrôle affiné.

Références

Licence

Wall-OSS-0.5 et Wall-X sont publiés sous licence Apache 2.0.

Update on GitHub