LeRobot documentation

Collecte de données avec intervention humaine

You are viewing main version, which requires installation from source. If you'd like regular pip install, checkout the latest stable version (v0.6.1).
Hugging Face's logo
Join the Hugging Face community

and get access to the augmented documentation experience

to get started

Collecte de données avec intervention humaine

La collecte de données avec intervention humaine (HIL) permet d’améliorer une politique entraînée en la déployant sur un robot réel, pendant qu’un opérateur humain surveille le processus et intervient si nécessaire. Les données d’intervention (mouvements de récupération et corrections) sont enregistrées aux côtés des segments autonomes, produisant un jeu de données d’entraînement plus riche qui enseigne à la politique comment gérer les échecs.


Pourquoi le Human-In-the-Loop ?

Le clonage comportemental standard entraîne les politiques uniquement sur des démonstrations réussies. Lors du déploiement, de petites erreurs peuvent s’accumuler et pousser le robot dans des états jamais vus pendant l’entraînement (dérive de distribution). La collecte de données HIL remédie à ce problème en :

  • Exécution de la politique entraînée sur le robot réel
  • Faire intervenir un humain lorsque le robot est sur le point d'échouer
  • Enregistrer la récupération et la correction de l’humain comme données d’entraînement
  • Ajustement fin de la politique sur le jeu de données combiné

Cela produit une politique qui sait non seulement comment effectuer la tâche, mais aussi comment se rétablir lorsque les choses tournent mal.


Fonctionnement

Lors d'une session HIL, l'opérateur humain suit cette boucle au sein de chaque épisode :

  1. Regarder la politique s'exécuter de manière autonome
  2. Pause lorsque l’échec est imminent, le robot maintient sa position
  3. Prenez le contrôle et téléopérez le robot pour le ramener dans un état correct (récupération), puis corrigez le comportement
  4. Restituer le contrôle à la politique, la politique reprend son exécution autonome
  5. Répétez les étapes 2 à 4 autant de fois que nécessaire pendant l'épisode
  6. Terminer l'épisode lorsque la tâche est terminée, enregistrer et passer au rollout suivant

Par défaut, seuls les segments contrôlés par l’humain (récupération et correction) sont enregistrés, et chaque correction devient un épisode distinct. Avec --strategy.record_autonomous=true, les segments autonomes sont également enregistrés : la politique et l’humain peuvent alterner le contrôle à plusieurs reprises, et l’exécution autonome, la récupération et la correction sont capturées dans une trajectoire continue. Dans les deux modes, le robot reprend depuis son état actuel après chaque transfert de contrôle (aucune réinitialisation n’est requise simplement parce qu’une intervention a eu lieu). Après la collecte, le jeu de données combiné (démonstrations d’origine + données HIL) est utilisé pour affiner la politique.

Ce processus peut être répété de manière itérative : déployer, collecter, affiner, répéter. Chaque itération cible les modes d’échec de la politique actuelle.

┌─────────────────────────────────────────────────────────────────────────┐
│  Policy v0 (trained on demos)                                           │
│       ↓                                                                 │
│  HIL Collection (target current failure modes) → Fine-tune → Policy v1  │
│       ↓                                                                 │
│  HIL Collection (target new failure modes) → Fine-tune → Policy v2      │
│       ↓                                                                 │
│  ... (repeat until satisfactory performance)                            │
└─────────────────────────────────────────────────────────────────────────┘

Exigences matérielles

Exigences du téléopérateur

Le mode lerobot-rollout --strategy.type=dagger nécessite des téléopérateurs avec des moteurs actifs capables de :

  • Activer/désactiver le couple de manière programmatique
  • Se déplacer vers les positions cibles (pour refléter l'état du robot lors d'une pause)

Lorsque vous mettez en pause, le bras leader se déplace pour s’aligner sur le robot, de sorte que le contrôle passe entre la politique et l’humain sans à-coups. Des à-coups finiraient par être intégrés aux corrections enregistrées et enseigneraient à la politique des trajectoires saccadées.

Opérateurs distants compatibles :

  • bi_openarm_mini - OpenArm Mini bimanuel
  • so100_leader / so101_leader - Bras leader SO100 / SO101
  • bi_so_leader - Bras leaders bimanuels SO100 / SO101

Les commandes fournies utilisent par défaut bi_openarm_follower + bi_openarm_mini. Les configurations SO100 / SO101 fonctionnent de la même manière, par exemple --robot.type=so101_follower avec --teleop.type=so101_leader.


Script

Utilisez lerobot-rollout avec --strategy.type=dagger pour la collecte de données HIL. Sélectionnez le backend d’inférence avec --inference.type=sync|rtc|remote :

ModeDrapeauModèles
Standard (par défaut)(aucun drapeau nécessaire)ACT, Diffusion Policy
Découpage en temps réel (RTC)--inference.type=rtcPi0, Pi0.5, SmolVLA
À distance--inference.type=remoteCheckpoint servi par lerobot-policy-server ; voir exigences de déploiement distant

Guide étape par étape

Étape 1 : Pré-entraîner une politique de base

Tout d'abord, entraînez une politique sur votre jeu de données de démonstration. Cet exemple entraîne ACT, qui s'exécute avec une inférence standard à l'étape 2 :

lerobot-train \
    --dataset.repo_id=${HF_USER}/demo-dataset \
    --policy.type=act \
    --policy.repo_id=${HF_USER}/act_pretrain \
    --output_dir=outputs/pretrain \
    --batch_size=32 \
    --steps=50000

Étape 2 : Collecter des données HIL

Inférence standard (ACT, Diffusion Policy) :

lerobot-rollout --strategy.type=dagger \
    --robot.type=bi_openarm_follower \
    --robot.left_arm_config.port=can1 \
    --robot.left_arm_config.side=left \
    --robot.right_arm_config.port=can0 \
    --robot.right_arm_config.side=right \
    --robot.cameras='{left_wrist: {type: opencv, index_or_path: "/dev/video0", width: 1280, height: 720, fps: 30}, right_wrist: {type: opencv, index_or_path: "/dev/video4", width: 1280, height: 720, fps: 30}, base: {type: opencv, index_or_path: "/dev/video2", width: 640, height: 480, fps: 30}}' \
    --teleop.type=bi_openarm_mini \
    --teleop.left_arm_config.port=/dev/ttyACM0 \
    --teleop.right_arm_config.port=/dev/ttyACM1 \
    --policy.path=outputs/pretrain/checkpoints/last/pretrained_model \
    --dataset.repo_id=${HF_USER}/rollout_hil_dataset \
    --dataset.single_task="Fold the T-shirt properly" \
    --dataset.fps=30 \
    --strategy.num_episodes=50 \
    --interpolation_multiplier=2

Avec --interpolation_multiplier=N, le robot reçoit N commandes interpolées par action de politique (la commande s’exécute à fps × N Hz) tandis que l’inférence de la politique et l’enregistrement du jeu de données restent à --fps, de sorte que le jeu de données enregistré correspond à son FPS déclaré.

Avec RTC pour les grands modèles (Pi0, Pi0.5, SmolVLA) :

Pour les modèles présentant une latence d’inférence élevée, activez le RTC pour une exécution fluide. Cela nécessite une politique de base VLA telle que Pi0, Pi0.5 ou SmolVLA, plutôt que la politique ACT de l’étape 1 :

lerobot-rollout --strategy.type=dagger \
    --inference.type=rtc \
    --inference.rtc.execution_horizon=20 \
    --inference.rtc.max_guidance_weight=5.0 \
    --inference.rtc.prefix_attention_schedule=LINEAR \
    --robot.type=bi_openarm_follower \
    --robot.left_arm_config.port=can1 \
    --robot.left_arm_config.side=left \
    --robot.right_arm_config.port=can0 \
    --robot.right_arm_config.side=right \
    --robot.cameras='{left_wrist: {type: opencv, index_or_path: "/dev/video0", width: 1280, height: 720, fps: 30}, right_wrist: {type: opencv, index_or_path: "/dev/video4", width: 1280, height: 720, fps: 30}, base: {type: opencv, index_or_path: "/dev/video2", width: 640, height: 480, fps: 30}}' \
    --teleop.type=bi_openarm_mini \
    --teleop.left_arm_config.port=/dev/ttyACM0 \
    --teleop.right_arm_config.port=/dev/ttyACM1 \
    --policy.path=outputs/pretrain/checkpoints/last/pretrained_model \
    --dataset.repo_id=${HF_USER}/rollout_hil_rtc_dataset \
    --dataset.single_task="Fold the T-shirt properly" \
    --dataset.fps=30 \
    --strategy.num_episodes=50 \
    --interpolation_multiplier=3

Contrôles :

CléAction
SpaceMettre la politique en pause / Reprendre la politique
TabDémarrer / arrêter une correction (uniquement en pause) ; les corrections sont enregistrées
EnterPousser le jeu de données vers le Hub (mode corrections uniquement)
ESCArrêter la session

Un pédale USB peut être utilisée à la place du clavier avec --strategy.input_device=pedal. Consultez Policy Deployment pour tous les drapeaux DAgger.

Le protocole HIL :

  1. Observer l'exécution autonome de la politique (la téléopération est inactive/libre)
  2. Lorsque vous constatez une défaillance imminente, appuyez sur Space pour mettre en pause
    • Arrêts de la politique
    • L'opérateur télécommandé se déplace pour correspondre à la position du robot (couple activé)
    • Aucune image enregistrée pendant la pause
  3. Appuyez sur Tab pour prendre le contrôle
    • Couple du téléopérateur désactivé, libre de se déplacer
    • Récupération : Téléopérer le robot pour le ramener à un bon état
    • Correction : corriger le comportement
    • Tous les mouvements sont enregistrés
  4. Appuyez sur Tab à nouveau pour terminer la correction, puis sur Space pour rendre le contrôle à la politique
    • La politique reprend l'exécution autonome à partir de l'état actuel
    • Vous pouvez intervenir à nouveau à tout moment (répétez les étapes 2 à 4)
  5. En mode par défaut, chaque correction est enregistrée en tant que son propre épisode. Avec --strategy.record_autonomous=true, tout est enregistré et découpé en épisodes automatiquement
  6. Appuyez sur ESC pour arrêter la session

Configuration de la pédale (Linux) :

Si vous utilisez une pédale USB (PCsensor FootSwitch), assurez-vous d’y avoir accès :

sudo setfacl -m u:$USER:rw /dev/input/by-id/usb-PCsensor_FootSwitch-event-kbd

Étape 3 : Fusionner les jeux de données

lerobot-rollout ajoute un horodatage au nom du jeu de données, de sorte que le jeu de données HIL de l’étape 2 est enregistré sous le nom your-username/rollout_hil_dataset_YYYYMMDD_HHMMSS. Utilisez ce nom complet ci-dessous.

Le jeu de données HIL comporte une colonne supplémentaire intervention qui marque les images contrôlées par un humain, et les jeux de données ne peuvent être fusionnés que s'ils possèdent les mêmes caractéristiques. Supprimez d'abord cette colonne, puis fusionnez les données HIL avec vos démonstrations :

lerobot-edit-dataset \
    --repo_id ${HF_USER}/rollout_hil_dataset_YYYYMMDD_HHMMSS \
    --new_repo_id ${HF_USER}/hil_dataset_no_intervention \
    --operation.type remove_feature \
    --operation.feature_names "['intervention']"

lerobot-edit-dataset \
    --new_repo_id ${HF_USER}/demo_plus_hil \
    --operation.type merge \
    --operation.repo_ids "['${HF_USER}/demo-dataset', '${HF_USER}/hil_dataset_no_intervention']"

Les deux jeux de données doivent également utiliser le même robot, les mêmes caméras et le même fps. Consultez Using Dataset Tools pour plus d'options de fusion.

Étape 4 : Ajustement fin de la Policy

Effectuez le fine-tuning de la politique de l'étape 1 sur le jeu de données fusionné :

lerobot-train \
    --dataset.repo_id=${HF_USER}/demo_plus_hil \
    --policy.path=outputs/pretrain/checkpoints/last/pretrained_model \
    --policy.repo_id=${HF_USER}/act_hil_finetune \
    --output_dir=outputs/hil_finetune \
    --steps=20000

Ensuite, déployez la politique affinée et répétez à partir de l'étape 2 pour cibler ses modes d'échec restants.


Conseils pour une collecte HIL efficace

Quand intervenir

Intervenez lorsque vous voyez :

  • Robot sur le point de commettre une erreur irréversible
  • Robot hésitant ou présentant un comportement incertain
  • Robot s'écartant de la trajectoire attendue

Récupération : téléopération pour revenir à un bon état

Pendant la récupération, téléopérez le robot pour le ramener à un état où :

  • Le robot est dans une configuration familière, dans la distribution
  • La sous-tâche actuelle peut toujours être terminée
  • La trajectoire de récupération elle-même constitue des données d'entraînement informatives

Qualité des corrections

Pendant la correction :

  • Fournir des trajectoires confiantes et propres
  • Terminez entièrement la sous-tâche en cours
  • Ne surcorrigez pas et n'ajoutez pas de mouvements inutiles

Travaux connexes

Cette approche de collecte de données HIL s'appuie sur des idées issues de l'apprentissage par imitation interactif :

  • DAgger (Ross et al., 2011) a introduit l’idée centrale : au lieu de s’entraîner uniquement sur des démonstrations d’experts, interroger l’expert pour obtenir des corrections sur les états visités par l’apprenant. Cela brise le cycle d’erreurs cumulées du clonage comportemental standard en collectant itérativement des données on-policy.

  • HG-DAgger (Kelly et al., 2019) a rendu cette approche pratique pour la robotique : un expert humain surveille le robot et n'intervient que lorsque c'est nécessaire, plutôt que d'annoter chaque état. Le mécanisme de bascule entre le contrôle autonome et le contrôle humain correspond exactement à la boucle pause → reprise en main → retour à la politique utilisée dans les scripts présentés ici.

  • RaC (Hu et al., 2025) étend cette boucle aux tâches de longue durée en décomposant explicitement les interventions en récupération (téléopération pour revenir à un bon état) et correction (démonstration du bon comportement à partir de là). Cette décomposition est le protocole suivi par la stratégie DAgger dans lerobot-rollout.

  • π0.6/RECAP (Physical Intelligence, 2025) applique la même boucle itérative de collecte et de fine-tuning à grande échelle avec des modèles VLA, démontrant que même les grandes politiques pré-entraînées bénéficient considérablement de corrections humaines ciblées sur leurs propres modes d’échec. π0.6 est entraîné en utilisant RECAP.

@article{ross2011dagger,
  title={A Reduction of Imitation Learning and Structured Prediction to No-Regret Online Learning},
  author={Ross, Stéphane and Gordon, Geoffrey and Bagnell, Drew},
  journal={Proceedings of the Fourteenth International Conference on Artificial Intelligence and Statistics},
  year={2011}
}

@article{kelly2019hgdagger,
  title={HG-DAgger: Interactive Imitation Learning with Human Experts},
  author={Kelly, Michael and Sidrane, Chelsea and Driggs-Campbell, Katherine and Kochenderfer, Mykel J},
  journal={arXiv preprint arXiv:1810.02890},
  year={2019}
}

@article{hu2025rac,
  title={RaC: Robot Learning for Long-Horizon Tasks by Scaling Recovery and Correction},
  author={Hu, Zheyuan and Wu, Robyn and Enock, Naveen and Li, Jasmine and Kadakia, Riya and Erickson, Zackory and Kumar, Aviral},
  journal={arXiv preprint arXiv:2509.07953},
  year={2025}
}

@article{pi2025recap,
  title={π0.6: a VLA That Learns From Experience},
  author={Physical Intelligence},
  year={2025}
}
Update on GitHub