Processadores de Ambiente

Os processadores de ambiente transformam as observações de um ambiente antes dos próprios processadores da política, e as ações da política antes do ambiente. Cada configuração de ambiente retorna seu par de get_env_processors(), e make_env_pre_post_processors os constrói para avaliação, avaliação durante o treinamento e um robô de simulação.

Ambientes simulados não precisam de nenhum

Ambientes simulados alcançam a política já em formato canônico: imagens como observation.images.<camera> (ou observation.image), o estado como um único observation.state plano, com a orientação das imagens e a composição do estado de cada simulador tratadas uma única vez pela sua integração src/lerobot/sim/integrations/<simulator>.py, para avaliação, rollout e gravação, localmente ou servido (veja Simulação: local ou servido). Para o LIBERO, por exemplo, seu adaptador de observação inverte ambas as câmeras e constrói o estado de 8 dimensões (posição do efector final, orientação eixo-ângulo, juntas do garra), de modo que seus processadores de ambiente são identidade.

Coloque o mapeamento de observação de um novo simulador em sua integração e as convenções de controle dele na função conventions() dessa integração, em vez de em um processador de ambiente, para que um robô de simulação e um ambiente servido também os recebam (veja Adicionando um benchmark).

Quando um processador de ambiente ainda é a ferramenta

• Ambientes fora do lerobot.sim. O Isaac Lab Arena é executado por meio do próprio make_env do repositório, com observações em lote do torch; o IsaaclabArenaProcessorStep seleciona e concatena suas chaves de estado e converte suas câmeras.
• Adaptações de ambiente específicas para cada política. make_env_pre_post_processors permite que uma política substitua o par do ambiente, como XVLA e Cosmos3 fazem para LIBERO.

A avaliação aceita um checkpoint com base no que seus processadores de ambiente produzem: a observação após o pré-processador e a ação após o pós-processador, ambos lidos de seus transform_features. Portanto, uma etapa declara sua saída ali como uma função de sua entrada, da forma como ela se comporta em tempo de execução, por exemplo, uma etapa que constrói o estado apenas quando sua chave de origem está presente. A inferência remota não aplica processadores de ambiente, portanto, um checkpoint servido lá precisa receber a observação do simulador e comandar sua ação por conta própria.

A ordem de processamento durante a avaliação é:

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

Escrevendo um

Um processador de ambiente é uma etapa de processador comum, retornada da configuração:

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=[])

Mantenha-o específico do ambiente (disposições de teclas, sistemas de coordenadas) e deixe a normalização e as transformações específicas do modelo para os processadores da política.