Découpage en temps réel (RTC)

Le découpage en temps réel (RTC) permet aux politiques robotiques de grande taille basées sur le flow matching, telles que Pi0, Pi0.5 et SmolVLA, de produire des mouvements fluides, continus et réactifs malgré une latence d'inférence élevée. LeRobot fournit le mode guidé à l'inférence d'origine ainsi que, pour les points de contrôle Pi05 compatibles, le conditionnement des actions à l'entraînement avec une inférence à préfixe dur économique.

Ces politiques génèrent des blocs d’actions futures (par exemple, 50 étapes à la fois) au lieu d’actions individuelles. Étant donné que les modèles sont volumineux, la production de chaque bloc prend plus de temps que l’exécution par le robot. Exécuter naïvement ces blocs entraîne des problèmes tels que des pauses, des transitions saccadées ou des changements soudains de stratégie chaque fois que le bloc suivant arrive en retard ou entre en contradiction avec les actions précédemment exécutées.

RTC résout ce problème en générant asynchronement le prochain bloc pendant que le robot continue d'exécuter le bloc actuel, et en guidant le nouveau bloc de manière à ce qu'il s'aligne en douceur avec la partie du bloc précédent qui a déjà été exécutée.

Fonctionnement de RTC (simplifié)

RTC permet au robot d’anticiper pendant qu’il est encore en mouvement. Lorsque le robot exécute un bloc d’actions, RTC commence à générer le bloc suivant en avance. Cependant, comme le robot a déjà effectué une partie de son déplacement au moment où le nouveau bloc est prêt, RTC doit s’assurer que ce nouveau bloc s’aligne toujours de manière fluide avec les actions actuellement en cours.

Pour ce faire, RTC traite le début du nouveau segment comme un problème d'inpainting ou de « comblement des lacunes » : il ajuste délicatement la première partie du nouveau segment afin qu'elle s'intègre naturellement au mouvement en cours du robot. Le résultat est l'absence de pauses et de sauts soudains.

En termes techniques, RTC ajoute un terme de guidage au processus de débruitage par flow-matching qui force les timesteps superposés du nouveau chunk à rester proches de la partie exécutée du chunk précédent, en utilisant typiquement un masque de transition douce.

Démarrage rapide

Installation

RTC est intégré à LeRobot. Il suffit d'installer les dépendances de la politique dont vous avez besoin :

# For Pi0 or Pi0.5
pip install -e ".[pi]"

# For SmolVLA
pip install -e ".[smolvla]"

Utilisation de RTC avec Pi0

Vous pouvez utiliser lerobot-rollout --strategy.type=base --inference.type=rtc pour le déploiement RTC sur des robots réels. L'extrait ci-dessous fournit un pseudo-exemple simplifié du fonctionnement de RTC avec Pi0 dans votre pipeline :

from lerobot.policies.pi0 import PI0Policy, PI0Config
from lerobot.configs import RTCAttentionSchedule
from lerobot.policies.rtc import RTCConfig, ActionQueue

# Load the Pi0 config so RTC can be enabled before the policy is built
policy_cfg = PI0Config.from_pretrained("lerobot/pi0_base")

# Enable RTC
policy_cfg.rtc_config = RTCConfig(
    enabled=True,
    execution_horizon=10,  # How many steps to blend with previous chunk
    max_guidance_weight=10.0,  # How strongly to enforce consistency
    prefix_attention_schedule=RTCAttentionSchedule.EXP,  # Exponential blend
)

# Load the policy
policy = PI0Policy.from_pretrained("lerobot/pi0_base", config=policy_cfg).to("cuda")

# Now use predict_action_chunk with RTC parameters
inference_delay = 4  # How many steps of inference latency, this value should be calculated based on the inference latency of the policy

# Initialize the action queue
action_queue = ActionQueue(policy_cfg.rtc_config)

# Start in a separate thread with the following function
def get_actions():
  while True:
    if should_get_actions:

      prev_actions = action_queue.get_left_over()
      obs = get_robot_observations(robot)

      # Generate actions WITH RTC
      actions = policy.predict_action_chunk(
          obs,
          inference_delay=inference_delay,
          prev_chunk_left_over=prev_actions,
      )

      action_queue.merge(
          actions, actions, inference_delay
      )

for step in range(num_steps):
    action = action_queue.get()

    # Execute the first N actions
    execute_actions(action)

Paramètres clés

RTCConfig possède les paramètres suivants à régler :

mode sélectionne la méthode de conditionnement par préfixe d’action :

• guided (par défaut) applique le guidage par jacobienne d’origine lors du débruitage et fonctionne avec les points de contrôle de correspondance de flux classiques.
• trained applique un hard-inpainting du préfixe du chunk précédent avec des timesteps de flux par action. Il nécessite actuellement un checkpoint Pi05 entraîné avec policy.rtc_training_max_delay > 0 et évite le passage arrière de guidance.

Le déploiement local et le serveur de politique appliquent la même règle d’admission conservatrice en mode d’entraînement : rtc_training_max_delay <= execution_horizon <= prediction_steps - rtc_training_max_delay. Pour Pi05, prediction_steps correspond à la chunk_size du point de contrôle. Cela préserve la limite locale existante : le préfixe configuré couvre le délai maximal entraîné et laisse au moins autant d’étapes prédites en dehors de celui-ci. Le déploiement local exige en outre que inference.queue_threshold >= rtc_training_max_delay avant de connecter le robot ; la chronologie des demandes distantes utilise ses propres paramètres de réapprovisionnement.

Ici, execution_horizon correspond à la capacité du préfixe fourni, et non à la quantité de lecture entre les requêtes. Pi05 conditionne uniquement le préfixe inference_delay. La règle d’admission n’est pas une garantie de latence ni une affirmation selon laquelle des capacités plus élevées doivent échouer à l’exécution ; la superposition mesurée, les actions restantes et les contrôles de fraîcheur déterminent toujours si un chunk retourné peut s’exécuter. Les chunks simples et le RTC guidé ne sont pas affectés par cette règle propre à l’entraînement.

execution_horizon : Nombre d'étapes de temps depuis le bloc précédent à conserver pour maintenir la cohérence. Des valeurs plus élevées signifient des transitions plus fluides, mais potentiellement moins de réactivité.

Valeurs typiques : 8-12 étapes

RTCConfig(execution_horizon=10)

max_guidance_weight : Intensité de l'application de la cohérence avec le bloc précédent. Il s'agit d'un hyperparamètre qui peut être ajusté pour équilibrer la fluidité des transitions et la réactivité de la politique. Pour le flow matching sur 10 étapes (SmolVLA, Pi0, Pi0.5), une valeur de 10.0 est optimale.

prefix_attention_schedule : Méthode de pondération de la cohérence sur la zone de chevauchement.

• LINEAR : Décroissance linéaire de inference_delay à execution_horizon
• EXP : Décroissance exponentielle (recommandée pour commencer)
• ONES : Poids complet sur l'ensemble de l'execution_horizon
• ZEROS : Binaire (poids complets jusqu'à inference_delay, puis zéro)

inference_delay : Nombre d'étapes d'inférence de latence de votre système. Cette valeur est transmise à predict_action_chunk() plutôt qu'au config, car elle peut varier à l'exécution.

Tester RTC hors ligne

Avant de l’exécuter sur un robot réel, testez RTC avec des échantillons du jeu de données pour visualiser son fonctionnement :

python examples/rtc/eval_dataset.py \
    --policy.path=lerobot/pi0_libero_finetuned \
    --dataset.repo_id=HuggingFaceVLA/libero \
    --rtc.execution_horizon=10 \
    --rtc.max_guidance_weight=10.0 \
    --device=cuda

Ajoutez --rtc.mode=trained lors de l’évaluation d’un checkpoint Pi05 compatible avec le RTC entraîné au moment de l’entraînement. Les politiques non prises en charge rejettent le mode entraîné au lieu de basculer sur le RTC guidé.

Le script génère une visualisation du processus de débruitage, comparant la génération standard (à gauche) avec RTC (à droite). Dans les graphiques RTC, vous pouvez observer comment les premières étapes (lignes bleues/violettes) sont guidées pour correspondre à la trajectoire de vérité terrain en rouge (la fin du chunk précédent), garantissant une transition fluide entre les chunks.

Tester RTC avec un robot réel

lerobot-rollout \
    --strategy.type=base \
    --policy.path=${HF_USERNAME}/policy_repo_id \
    --inference.type=rtc \
    --inference.rtc.mode=guided \
    --inference.rtc.execution_horizon=10 \
    --inference.rtc.max_guidance_weight=10.0 \
    --robot.type=so100_follower \
    --robot.port=/dev/tty.usbmodem58FA0834591 \
    --robot.cameras="{ gripper: {type: opencv, index_or_path: 1, width: 640, height: 480, fps: 30}, front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}}" \
    --task="Move green small object into the purple platform" \
    --duration=120 \
    --device=cuda

Pour un point de contrôle RTC Pi05 de temps d’entraînement, changez le mode en trained. Le point de contrôle enregistre le délai maximal pris en charge, et le déroulement valide la latence mesurée par rapport à celui-ci :

lerobot-rollout \
    --strategy.type=base \
    --policy.path=${HF_USERNAME}/pi05_training_rtc \
    --inference.type=rtc \
    --inference.rtc.mode=trained \
    --inference.rtc.execution_horizon=10 \
    --robot.type=so100_follower \
    --robot.port=/dev/tty.usbmodem58FA0834591 \
    --task="Move green small object into the purple platform" \
    --duration=120 \
    --device=cuda

Comment RTC se rapporte à l’inférence distante

--inference.type=rtc correspond à un RTC local : l’inférence s’exécute dans un thread en arrière-plan du processus de rollout et n’utilise aucun transport. Lancer un serveur de politique et un client robot comme des processus distincts sur la même machine utilise à la place le backend distant.

Les deux backends asynchrones utilisent le même comportement d’attente bornée et d’arrêt sur les robots pris en charge. Consultez les budgets RTC locaux pour les valeurs par défaut de délai d’attente. L’attente ne relâche pas les vérifications de préfixe, de délai ou de fraîcheur de RTC.

RTC et l'inférence distante améliorent tous deux le contrôle en temps réel des robots, mais ils résolvent des problèmes différents.

L'inférence distante peut utiliser le RTC lorsque le point de contrôle prend en charge le mode RTC négocié. Les blocs simples prennent également en charge l'alignement et le mélange de curseur optionnels ; consultez le guide d'inférence distante pour les modes, la compatibilité et l'ajustement.

Avancé : Suivi du débogage

RTC intègre un suivi de débogage intégré pour vous aider à comprendre ce qui se passe pendant l'inférence :

# Enable debug tracking
policy_cfg.rtc_config.debug = True
policy_cfg.rtc_config.debug_maxlen = 100
policy.init_rtc_processor()  # re-create the RTC processor so the new debug settings take effect

# After inference, access debug data
debug_data = policy.rtc_processor.get_all_debug_steps()

# Visualize denoising steps, corrections, etc.
from lerobot.policies.rtc.debug_visualizer import RTCDebugVisualizer
visualizer = RTCDebugVisualizer()
# ... create plots

Consultez examples/rtc/eval_dataset.py pour un exemple complet de visualisation RTC hors ligne.

Références

• Politiques robotiques fluides comme du beurre - Explication technique excellente avec des résultats sur robot réel
• Physical Intelligence - Chunking en temps réel - Article et recherche originaux
• Implémentation Kinetix RTC - Implémentation de référence de Physical Intelligence
• Conditionnement d'action au moment de l'entraînement - RTC efficace avec un conditionnement par préfixe propre pendant l'entraînement
• RLDX-1 - Référence PyTorch utilisée pour l'intégration du RTC au moment de l'entraînement