Fix: rename_map ignored when use_relative_actions=true

[wadeKeith]

Fix for Issue #3425

When training PI05 (or PI0, PI0Fast, SmolVLA, XVLA) with use_relative_actions=true, the rename_map argument was silently ignored. This caused training to fail because image feature names from the dataset didn't match what the policy expected.

Root Cause

When use_relative_actions=true with a pretrained model, the code sets processor_pretrained_path=None to force building processors from the current policy config rather than loading from the checkpoint. However, rename_map was only being passed via preprocessor_overrides which only applies when loading from pretrained. This meant rename_map was silently ignored when use_relative_actions=true.

Solution

1. Add rename_map to ProcessorConfigKwargs TypedDict in factory.py
2. Always pass rename_map to make_pre_post_processors (when not reward model training)
3. Update all affected processor factories to accept and use rename_map:
   • make_pi05_pre_post_processors
   • make_pi0_pre_post_processors
   • make_pi0_fast_pre_post_processors
   • make_smolvla_pre_post_processors
   • make_xvla_pre_post_processors

This ensures the RenameObservationsProcessorStep uses the user-provided rename_map regardless of whether processors are loaded from pretrained or built from scratch.

---

[Copilot]

Pull request overview

Fix intended to ensure --rename_map is applied even when use_relative_actions=true forces processor construction from the current policy config (instead of loading processors from the pretrained checkpoint), preventing image/state key mismatches between dataset batches and policy expectations.

Changes:

• Adds rename_map into the training script’s processor kwargs so it can be used when building processors from scratch.
• Extends PI0/PI05/PI0Fast/SmolVLA/XVLA processor factory functions to accept rename_map and wire it into RenameObservationsProcessorStep.
• Adds rename_map to ProcessorConfigKwargs in policies/factory.py.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/lerobot/scripts/lerobot_train.py	Passes rename_map into processor construction kwargs for non-reward training.
src/lerobot/policies/factory.py	Extends ProcessorConfigKwargs with rename_map (but currently does not propagate it to per-policy builders when not loading from pretrained).
src/lerobot/policies/pi05/processor_pi05.py	Accepts rename_map and applies it in RenameObservationsProcessorStep.
src/lerobot/policies/pi0/processor_pi0.py	Accepts rename_map and applies it in RenameObservationsProcessorStep.
src/lerobot/policies/pi0_fast/processor_pi0_fast.py	Accepts rename_map and applies it in RenameObservationsProcessorStep.
src/lerobot/policies/smolvla/processor_smolvla.py	Accepts rename_map and applies it in RenameObservationsProcessorStep.
src/lerobot/policies/xvla/processor_xvla.py	Accepts rename_map and applies it in RenameObservationsProcessorStep.

Comments suppressed due to low confidence (1)

src/lerobot/policies/factory.py:233

• rename_map is added to processor_kwargs, but make_pre_post_processors() currently never forwards kwargs.get("rename_map") into the policy-specific make_*_pre_post_processors(...) calls when building processors from scratch. As a result, rename_map will still be ignored in the processor_pretrained_path=None path (the reported use_relative_actions=true case). Forward rename_map from make_pre_post_processors into the PI0/PI05/PI0Fast/SmolVLA/XVLA processor factories (and/or apply it via a shared overrides mechanism) so the RenameObservationsProcessorStep gets the user mapping.

    preprocessor_config_filename: str | None
    postprocessor_config_filename: str | None
    preprocessor_overrides: dict[str, Any] | None
    postprocessor_overrides: dict[str, Any] | None
    dataset_stats: dict[str, dict[str, torch.Tensor]] | None
    rename_map: dict[str, str] | None


def make_pre_post_processors(
    policy_cfg: PreTrainedConfig,
    pretrained_path: str | None = None,
    **kwargs: Unpack[ProcessorConfigKwargs],

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[wadeKeith]

All Copilot review concerns are now addressed in PR #3514, which supersedes #3512:

1. dataset_stats rename: When rename_map is active in the fresh-build path, rename_stats() is called on dataset.meta.stats before passing to make_pre_post_processors. This ensures NormalizerProcessorStep finds stats by renamed keys.

2. Plugin backward-compat: _make_processors_from_policy_config() now uses inspect.signature() to check if the target factory accepts rename_map. Falls back to (config, dataset_stats) for third-party factories that don't declare the parameter.

3. Docstring: ProcessorConfigKwargs docstring now documents rename_map and explains its effect on stats.