# 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](./simulation)). 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](./adding_benchmarks)).

## 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 é:

```python
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:

```python
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.