Segmentación en tiempo real (RTC)

El chunking en tiempo real (RTC) permite que las políticas robóticas grandes basadas en flow matching, como Pi0, Pi0.5 y SmolVLA, generen un movimiento suave, continuo y reactivo a pesar de tener una latencia de inferencia alta. LeRobot proporciona el modo original de inferencia guiada en tiempo de ejecución y, para los checkpoints compatibles de Pi05, el condicionamiento de acciones en tiempo de entrenamiento con inferencia de prefijo duro de bajo costo.

Estas políticas generan fragmentos de acciones futuras (p. ej., 50 pasos a la vez) en lugar de acciones individuales. Dado que los modelos son grandes, generar cada fragmento toma más tiempo que el que tarda el robot en ejecutarlo. Ejecutar los fragmentos de forma ingenua provoca problemas como pausas, transiciones bruscas o cambios repentinos de estrategia cada vez que el siguiente fragmento llega tarde o no coincide con las acciones ejecutadas previamente.

RTC resuelve esto generando asincrónicamente el siguiente fragmento mientras el robot continúa ejecutando el actual, y guiando el nuevo fragmento para que se alinee de forma fluida con la parte del fragmento anterior que ya se ha ejecutado.

Cómo funciona RTC (simplificado)

RTC permite que el robot anticipe mientras aún se está moviendo. Cuando el robot está ejecutando un bloque de acciones, RTC comienza a crear el siguiente bloque con antelación. Pero como el robot ya se ha movido un poco para cuando el nuevo bloque está listo, RTC debe asegurarse de que el nuevo bloque se alinee suavemente con lo que el robot está haciendo actualmente.

Para lograr esto, RTC trata el inicio del nuevo fragmento como un problema de inpainting o “relleno de huecos”: ajusta suavemente la primera parte del nuevo fragmento para que se integre de forma natural con el movimiento continuo del robot. El resultado son pausas y saltos repentinos inexistentes.

En términos técnicos, RTC añade un término de guía al proceso de desruido de flow-matching que obliga a los pasos de tiempo superpuestos del nuevo bloque a permanecer cerca de la parte ejecutada del bloque anterior, generalmente utilizando una máscara de transición suave.

Inicio rápido

Instalación

RTC está integrado en LeRobot. Solo instala las dependencias de la política que necesites:

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

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

Uso de RTC con Pi0

Puede usar lerobot-rollout --strategy.type=base --inference.type=rtc para el despliegue de RTC en robots reales. El fragmento de código a continuación proporciona un ejemplo pseudo simplificado de cómo opera RTC con Pi0 en su 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)

Parámetros clave

RTCConfig tiene los siguientes parámetros para ajustar:

mode selecciona el método de condicionamiento por prefijo de acción:

• guided (predeterminado) aplica la guía original de Jacobiano durante el desruido y funciona con puntos de control de flujo de correspondencia ordinarios.
• trained realiza un hard-inpaint del prefijo del chunk anterior con timesteps de flujo por acción. Actualmente requiere un checkpoint de Pi05 entrenado con policy.rtc_training_max_delay > 0 y evita el paso de retropropagación de la guía.

El despliegue local y el servidor de política aplican la misma regla de admisión conservadora del modo de entrenamiento: rtc_training_max_delay <= execution_horizon <= prediction_steps - rtc_training_max_delay. Para Pi05, prediction_steps es el chunk_size del punto de control. Esto preserva el límite local existente: el prefijo configurado cubre el retardo máximo entrenado y deja al menos ese número de pasos predichos fuera de él. El despliegue local requiere además que inference.queue_threshold >= rtc_training_max_delay antes de conectar el robot; el temporizado de las solicitudes remotas utiliza sus propias configuraciones de relleno.

Aquí execution_horizon es la capacidad del prefijo proporcionado, no la cantidad de reproducción entre solicitudes. Pi05 condiciona de forma estricta solo el prefijo de inference_delay. La regla de admisión no es una garantía de latencia ni una afirmación de que las capacidades mayores deben fallar en tiempo de ejecución; la superposición medida, las acciones restantes y las comprobaciones de vigencia siguen determinando si un fragmento devuelto puede ejecutarse. Los fragmentos simples y el RTC guiado no se ven afectados por esta regla exclusiva de entrenamiento.

execution_horizon: Número de pasos de tiempo desde el fragmento anterior con los que mantener la consistencia. Valores más altos producen transiciones más suaves, pero posiblemente con menos reactividad.

Valores típicos: 8-12 pasos

RTCConfig(execution_horizon=10)

max_guidance_weight: Qué tan fuerte se debe aplicar la consistencia con el fragmento anterior. Este es un hiperparámetro que se puede ajustar para equilibrar la suavidad de las transiciones y la reactividad de la política. Para 10 pasos de flow matching (SmolVLA, Pi0, Pi0.5), un valor de 10.0 es óptimo.

prefix_attention_schedule: Cómo ponderar la consistencia en la región de solapamiento.

• LINEAR: Decaimiento lineal desde inference_delay hasta execution_horizon
• EXP: Decaimiento exponencial (recomendado para empezar)
• ONES: Peso completo en todo el execution_horizon
• ZEROS: Binario (peso completo hasta inference_delay, luego cero)

inference_delay: Número de pasos de inferencia de latencia que tiene su sistema. Esto se pasa a predict_action_chunk() en lugar de a la configuración, ya que puede variar en tiempo de ejecución.

Pruebas de RTC sin conexión

Antes de ejecutarlo en un robot real, pruebe RTC con muestras del conjunto de datos para visualizar cómo funciona:

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

Añada --rtc.mode=trained al evaluar un checkpoint compatible de RTC Pi05 de tiempo de entrenamiento. Las políticas no compatibles rechazan el modo trained en lugar de volver a RTC guiado.

El script genera una visualización del proceso de desruido, comparando la generación estándar (izquierda) con RTC (derecha). En las gráficas de RTC, se puede ver cómo los primeros pasos (líneas azules/moradas) se guían para que coincidan con la trayectoria de referencia en rojo (cola del fragmento anterior), garantizando una transición fluida entre fragmentos.

Pruebas de RTC con un robot real

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

Para un punto de control de RTC Pi05 de tiempo de entrenamiento, cambia el modo a trained. El punto de control registra su retraso máximo admitido, y el rollout valida la latencia medida contra este:

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

Cómo se relaciona RTC con la inferencia remota

--inference.type=rtc es RTC local: la inferencia se ejecuta en un hilo en segundo plano dentro del proceso de rollout y no utiliza transporte. Ejecutar un servidor de política y un cliente de robot como procesos separados en la misma máquina utiliza el backend remoto en su lugar.

Ambos backends asincrónicos utilizan el mismo comportamiento de espera acotada y cierre en los robots compatibles. Consulte presupuestos de RTC local para los valores predeterminados de su tiempo de espera. La espera no relaja las comprobaciones de prefijo, retraso o frescura de RTC.

Tanto RTC como inferencia remota mejoran el control de robots en tiempo real, pero resuelven problemas diferentes.

La inferencia remota puede usar RTC cuando el checkpoint admite el modo de RTC negociado. Los fragmentos simples también admiten la alineación opcional del cursor y el mezclado; consulte la guía de inferencia remota para conocer los modos, la compatibilidad y el ajuste.

Avanzado: Seguimiento de depuración

RTC incluye un seguimiento de depuración integrado para ayudarte a entender lo que ocurre durante la inferencia:

# 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

Vea examples/rtc/eval_dataset.py para un ejemplo completo de visualización de RTC sin conexión.

Referencias

• Políticas de robot suaves como la mantequilla - Excelente explicación técnica con resultados de robots reales
• Physical Intelligence - Chunking en tiempo real - Artículo y investigación originales
• Implementación de Kinetix RTC - Implementación de referencia de Physical Intelligence
• Condicionamiento de acciones en tiempo de entrenamiento - RTC eficiente con condicionamiento de prefijo limpio durante el entrenamiento
• RLDX-1 - Referencia de PyTorch utilizada para la integración de RTC en tiempo de entrenamiento