Procesadores de entorno

Los procesadores de entorno transforman las observaciones de un entorno antes de los propios procesadores de la política, y las acciones de la política antes del entorno. Cada configuración de entorno devuelve su par desde get_env_processors(), y make_env_pre_post_processors los construye para la evaluación, la evaluación durante el entrenamiento y un robot simulado.

Los entornos simulados no necesitan ninguno

Los entornos simulados llegan a la política ya en formato canónico: las imágenes como observation.images.<camera> (o observation.image), el estado como un único observation.state plano, con la orientación de las imágenes y la composición del estado de cada simulador gestionadas una sola vez por su integración src/lerobot/sim/integrations/<simulator>.py, tanto para evaluación, rollout como grabación, ya sea local o servido (ver Simulación: local o servido). Por ejemplo, en el caso de LIBERO, su adaptador de observación invierte ambas cámaras y construye el estado de 8 dimensiones (posición del efector final, orientación axis-angle, articulaciones del agarre), por lo que sus procesadores de entorno son identidad.

Coloca el mapeo de observaciones de un nuevo simulador en su integración y sus convenciones de control en la función conventions() de esa integración, en lugar de en un procesador de entorno, para que un robot simulado y un entorno servido también las reciban (consulta Adding a benchmark).

Cuando un procesador de entorno sigue siendo la herramienta

• Entornos fuera de lerobot.sim. Isaac Lab Arena se ejecuta a través de su propio make_env en el repositorio, con observaciones de torch por lotes; IsaaclabArenaProcessorStep selecciona y concatena sus claves de estado y convierte sus cámaras.
• Adaptaciones de entorno específicas de la política. make_env_pre_post_processors permite que una política reemplace el par del entorno, como hacen XVLA y Cosmos3 para LIBERO.

La evaluación admite un punto de control sobre lo que producen sus procesadores de entorno: la observación después del preprocesador y la acción después del posprocesador, ambas leídas de su transform_features. Un paso, por lo tanto, declara su salida allí como una función de su entrada, de la manera en que se comporta en tiempo de ejecución, por ejemplo, un paso que construye el estado solo cuando su clave de origen está presente. La inferencia remota no aplica procesadores de entorno, por lo que un punto de control servido allí debe tomar la observación del simulador y comandar su acción por sí mismo.

El orden de procesamiento durante la evaluación es:

observation = env_preprocessor(observation)   # environment-specific
observation = preprocessor(observation)       # policy's saved preprocessing (normalization, ...)
action = postprocessor(policy.select_action(observation))
action = env_postprocessor(action)            # environment-specific

Escribir uno

Un procesador de entorno es un paso de procesador ordinario, devuelto desde la configuración:

from dataclasses import dataclass

from lerobot.envs.configs import EnvConfig
from lerobot.processor import ObservationProcessorStep, PolicyProcessorPipeline, ProcessorStepRegistry


@dataclass
@ProcessorStepRegistry.register(name="myenv_processor")
class MyEnvProcessorStep(ObservationProcessorStep):
    def observation(self, observation):
        processed = observation.copy()
        processed["observation.state"] = processed.pop("observation.myenv_state")
        return processed

    def transform_features(self, features):
        return features  # update if names or shapes change


@EnvConfig.register_subclass("myenv")
@dataclass
class MyEnvConfig(EnvConfig):
    ...

    def get_env_processors(self):
        return PolicyProcessorPipeline(steps=[MyEnvProcessorStep()]), PolicyProcessorPipeline(steps=[])

Manténgalo específico del entorno (disposiciones de teclas, marcos de coordenadas) y deje la normalización y las transformaciones específicas del modelo a los procesadores de la política.