Use a LeRobot rename map when an available observation has the right meaning but a different key from the one the policy expects. Use a supported missing-camera mechanism when a view is genuinely absent. Renaming changes the observation’s address; masking changes which visual slots participate in the model.
Suppose a dataset calls its front camera observation.images.front, while a checkpoint expects observation.images.image. A mapping can connect those names. It cannot turn a front-facing camera into the wrist view that another checkpoint was trained to use. Check the physical view before treating the names as interchangeable.
Map from the data source to the policy
The LeRobot rename-map documentation defines the mapping direction as source key to policy key. The mapping operates on observations, including images and state; the documented interface does not rename actions. Unlisted observation keys keep their names.
For a front camera that really supplies the expected view, the mapping could be written as this configuration fragment:
{"observation.images.front": "observation.images.image"}
This fragment illustrates the direction of the mapping; it is not a complete training command. The checkpoint, processor and dataset configuration still determine how the resulting observation is used.
Inspect three names together: the source feature, the mapped feature and the checkpoint’s expected feature. Also retain the source camera identity. An error that says a key is missing often reveals a naming mismatch, but fixing that error is only the first part of connecting the correct view.
Keep preprocessing metadata attached to the renamed feature
The pinned rename processor preserves the observation value while changing its dictionary key. Its helper also carries recognized temporal metadata suffixes, such as _is_pad and _padding_mask, across the rename. A separate rename_stats helper maps statistics keys.
This makes the surrounding preprocessing worth checking. A state vector named correctly but normalized using statistics for another feature can reach the model with the wrong scale. Similarly, changing a camera label without retaining the intended temporal padding mask can alter which samples the model treats as valid.
Avoid mapping two supplied features onto one destination. The processor builds an output dictionary keyed by the renamed names; repeated destination names cannot preserve two independent values in that dictionary. This is a source-code consequence, not an observed training failure from a run here.
An empty camera is a model-specific masked slot
The documentation lists PI0, PI05, PI0Fast, SmolVLA and XVLA for its rename-map and empty-camera workflow. It describes empty_cameras as adding masked feature slots when fewer camera streams are available. Check the installed policy implementation rather than extending that support list to an unrelated model.
The numerical contents of an unused slot are not universal. For example, the checked XVLA image preparation code gathers present image keys, prepares their images and masks, then pads unused view positions with zero-valued tensors and false masks. It raises an error when every image feature is absent. The policy-specific mask is what identifies an unused view.
That is different from storing a fabricated camera stream in the dataset. It is also different from feeding a real black image as a valid observation. Keep missingness explicit so downstream code can distinguish the two situations.
| Situation | Appropriate next action |
|---|---|
| Correct camera, different feature name | Add a source-to-policy observation mapping |
| Wrong camera pose or field of view | Revisit the observation setup or adaptation data |
| Fewer real views than expected | Check the selected policy’s supported masked-camera path |
| Two inputs would share one destination name | Resolve the mapping collision before inference |
| Correct keys but unusual value ranges | Inspect the associated preprocessing and statistics |
Inspect the batch that reaches the model
Choose one dataset sample and list its camera keys, image shapes, validity masks and state preprocessing before and after the processor. Match each surviving view to the physical camera that produced it. If a view is masked, confirm that the selected policy receives that mask through its actual input path.
The LeRobot dataset-format guide explains the stored relationship between frames and episode metadata. This check begins after loading, where those stored features become the checkpoint’s observations.
Documentation and LeRobot revision 146d8474932c8b566717eb2738ba459337ab71c4 were inspected on October 16, 2026. No checkpoint was loaded for this article. The outcome to seek in an implementation is a short, inspectable mapping from each real sensor to its intended model input, with absent views identified explicitly.