Normalisation Statistics and Why They Break Training Runs

A vision-language-action policy never sees your robot's joint angles. It sees numbers that have been shifted and scaled into roughly [-1, 1], trained on those, and predicts in that space. The shift and the scale come from a small metadata file: the dataset statistics. Get that file wrong and nothing crashes. The loss curve looks fine, the checkpoint saves, and the arm does something dull and confidently wrong.

This page is about that file. What is in it, where each trainer keeps it, why it has to be regenerated when you change how actions are represented, and the specific errors that follow when you do not. The numbers below are computed from the cube_to_bowl_5 demo dataset that ships inside NVIDIA's Isaac-GR00T repository, so you can reproduce every one of them. Versions checked on 2026-08-23: lerobot 0.6.2 on main, Isaac-GR00T main (gr00t 0.1.0), openpi main.

What is actually in a stats file

A LeRobot dataset stores raw sensor and motor values. Joint angles in degrees, gripper aperture in whatever unit your calibration produced, image tensors in 0 to 255. A neural network trained directly on that mix would spend its capacity learning that elbow_flex lives around 50 and wrist_roll around -1.6. So every trainer normalises first, and the parameters of that normalisation are computed once over the whole dataset and written to a metadata file.

In LeRobot this file is meta/stats.json. It holds one entry per feature key, and each entry holds a fixed set of per-dimension arrays. LeRobot's default quantile list is [0.01, 0.10, 0.50, 0.90, 0.99], so a fully populated entry carries mean, std, min, max, count and the five quantiles. GR00T computes a narrower set: mean, std, min, max, q01, q99.

{
  "action": {
    "mean": [  2.01, -58.36,  52.07,  84.16,  -1.61,   9.50],
    "std":  [ 10.54,  57.81,  64.36,  10.12,   2.42,  15.96],
    "min":  [-29.98, -100.0, -97.84,  25.30, -11.13,   0.41],
    "max":  [ 12.48,  59.79,  99.61, 100.00,   3.92,  63.69],
    "q01":  [-28.77, -99.39, -91.99,  46.93, -11.08,   0.41],
    "q99":  [ 11.08,  56.50,  97.64, 100.00,   2.77,  63.11]
  }
}

Two things are worth noticing in those numbers. The fourth dimension, wrist_flex, has a q01 of 46.93 against a min of 25.30: the joint spends 99 percent of its frames above roughly 47 degrees and drops far below that in the remaining 1 percent. And min for shoulder_lift is exactly -100.0 while q01 is -99.39, which is the signature of a joint that touched a software limit in at least one episode. That gap between min and q01 is why GR00T defaults to percentiles rather than raw extremes.

Where each trainer keeps its statistics

Three ecosystems, three conventions. If you train more than one policy family on the same data, you will end up with all three on disk.

Normalisation modes, and which policy uses which

LeRobot's NormalizationMode enum has five members: MIN_MAX, MEAN_STD, IDENTITY, QUANTILES and QUANTILE10. Each policy config declares a mapping from feature type to mode, and those defaults differ in ways that matter for which statistics your dataset needs to carry.

The practical consequence: a dataset recorded before quantile statistics existed will train ACT and SmolVLA without complaint and refuse Pi0.5 outright, with the message QUANTILES normalization mode requires q01 and q99 stats, please update the dataset with the correct stats using the `augment_dataset_quantile_stats.py` script. That is one of the few places in this whole area where you get a clear error instead of a bad policy.

normalised = 2 * (x - min) / (max - min) - 1
raw        = (normalised + 1) / 2 * (max - min) + min

# GR00T then applies, with clip_outliers=True by default:
normalised = clip(normalised, -1.0, 1.0)

Absolute, relative and delta are different numbers in the same column

An action chunk can express the same motion in three ways. LeRobot's own documentation follows the terminology from the Universal Manipulation Interface paper: absolute, relative and delta. Absolute is the default everywhere. Relative subtracts the current state once, so every step in the chunk is an offset from the same reference. Delta subtracts the previous action, so errors accumulate along the chunk, which is why UMI argues against it.

The GR00T example config for the SO-100 makes the mixture explicit and it is worth reading closely, because it is the exact shape that trips people up: the arm joints are relative, the gripper is absolute, in the same action vector.

"action": ModalityConfig(
    delta_indices=list(range(0, 16)),   # predict 16 future steps
    modality_keys=["single_arm", "gripper"],
    action_configs=[
        # single_arm: RELATIVE = delta from current state
        ActionConfig(rep=ActionRepresentation.RELATIVE,
                     type=ActionType.NON_EEF,
                     format=ActionFormat.DEFAULT),
        # gripper: ABSOLUTE = target position
        ActionConfig(rep=ActionRepresentation.ABSOLUTE,
                     type=ActionType.NON_EEF,
                     format=ActionFormat.DEFAULT),
    ],
),

The failure: same file, different meaning

Here is the whole problem in one sentence. A stats file records what the numbers were, not what the numbers meant. Nothing in meta/stats.json says whether the action column it summarises was absolute or relative. So when you flip the representation and reuse the old file, the normaliser applies a perfectly valid affine map derived from the wrong distribution.

The table below is computed from the shipped GR00T demo dataset. Column two is the absolute action range from meta/stats.json. Column three is the relative range for the first step of the chunk from meta/relative_stats.json. Column four is what happens when relative action values are normalised with the absolute statistics, which is exactly what you get if you switch on relative actions and skip the regeneration step.

Read the wrist_flex row again. In the absolute dataset the q01 to q99 band for that joint is 47 to 100 degrees. Relative offsets around zero are therefore far below the recorded minimum, the normalised value comes out at -3.04 to -2.34, and GR00T's clip_outliers=True default squashes every single one to exactly -1. The training target for that joint is a constant. The model dutifully learns to output a constant, the loss for that dimension drops to near zero, and the wrist never moves. That is the textbook shape of loss falls but the policy does nothing.

The reverse direction is quieter but not harmless. Even in the rows above where nothing clips, the real signal occupies 16 to 22 percent of the representable range. Since the same wrong map is applied in both directions at inference, min-max normalisation does round-trip cleanly, so the policy is not immediately broken. What breaks is learning: the differences that matter are compressed into a narrow band, while the flow-matching or diffusion head is being asked to resolve them against noise defined over the full range.

joint            absolute std   relative std (step 0)   ratio
shoulder_pan          10.54            1.13             9.3x
shoulder_lift         57.81            3.61            16.0x
elbow_flex            64.36            5.19            12.4x
wrist_flex            10.12            3.00             3.4x
wrist_roll             2.42            0.40             6.0x

Regenerating statistics: the actual commands

All three stacks give you a way to do this from a terminal, and none of them needs a GPU. Regeneration is a CPU pass over the parquet files. Do it before you rent anything, not after; see what a run costs on the pricing page for why the ordering matters.

1. 1
   LeRobot: recompute absolute statistics

   The plain form. Use this after you add, delete or trim episodes, because LeRobot has no content fingerprint and will happily keep serving the old file. Note where the result lands: without --new_repo_id this writes a new dataset called your_user/your_dataset_recomputed_stats, and editing the input dataset in place additionally requires --operation.overwrite true.

   bash

   lerobot-edit-dataset \
       --repo_id your_user/your_dataset \
       --operation.type recompute_stats

2. 2
   LeRobot: add quantiles to an older dataset

   Required before Pi0.5 will train, because its normalisation mapping is QUANTILES for both state and action. Add --overwrite to replace quantiles that are already present, --skip-images to leave video features alone.

   bash

   python src/lerobot/scripts/augment_dataset_quantile_stats.py \
       --repo-id your_user/your_dataset \
       --skip-images

3. 3
   LeRobot: relative action statistics for the pi family

   chunk_size should match your policy chunk size. relative_exclude_joints keeps listed dimensions in absolute space; it defaults to ['gripper'] and you almost always want that, because a binary open/close signal gains nothing from being expressed as an offset. The same output rule applies here: the recomputed dataset is written to your_user/your_dataset_recomputed_stats unless you say otherwise, so point the training run at that repo id and not at the original.

   bash

   lerobot-edit-dataset \
       --repo_id your_user/your_dataset \
       --operation.type recompute_stats \
       --operation.relative_action true \
       --operation.chunk_size 50 \
       --operation.relative_exclude_joints "['gripper']"

4. 4
   LeRobot: train with the matching flag

   This flag and the previous command are a pair. Setting one without the other is the failure this whole article is about. use_relative_actions defaults to false.

   bash

   lerobot-train \
       --dataset.repo_id=your_user/your_dataset \
       --policy.type=pi05 \
       --policy.use_relative_actions=true \
       --policy.relative_exclude_joints='["gripper"]'

5. 5
   Isaac-GR00T: generate both stats files

   A tyro CLI. It writes meta/stats.json and, for every action key marked RELATIVE in your modality config, meta/relative_stats.json. The --modality-config-path argument is required for NEW_EMBODIMENT, which is what a custom SO-100 setup uses.

   bash

   python gr00t/data/stats.py \
       --dataset-path ./my_so100_dataset \
       --embodiment-tag NEW_EMBODIMENT \
       --modality-config-path examples/SO100/so100_config.py

6. 6
   openpi: compute norm stats for a config

   openpi computes statistics after running the data transforms, so if your config includes DeltaActions the resulting norm_stats.json is already in the relative space. This is the cleanest of the three designs, because the representation cannot drift away from the statistics.

   bash

   uv run scripts/compute_norm_stats.py --config-name pi05_libero

What GR00T does for you, and what it still does not

GR00T is the only one of the three that tries to protect you. Its dataset factory calls generate_stats and generate_rel_stats on rank zero at the start of every fine-tune, so you rarely have to run the script by hand. And it fingerprints the cached entries so that a configuration change invalidates them.

There is a second GR00T trap worth naming, because it produces no error at all. When the fine-tuning pipeline merges your dataset's statistics into the processor, it calls set_statistics with override=False by default. If the base checkpoint already carries statistics for the embodiment tag you selected, your dataset's merged statistics are discarded and only a log warning records it. Using NEW_EMBODIMENT for a custom SO-100 avoids this, because the base model has no statistics under that tag.

ValueError: Relative action statistics required for embodiment 'new_embodiment'
            but 'relative_action' not found in statistics

ValueError: Relative action statistics required for key 'single_arm'
            in embodiment 'new_embodiment' but not found

WARNING  Statistics for embodiment 'oxe_droid_relative_eef_relative_joint'
         already present; new stats DISCARDED (override=False). If the new
         data differs from the existing distribution this will cause silent
         normalization mismatch

Two ways to get this right

# write the relative-stats copy to its own repo id
lerobot-edit-dataset --repo_id me/task \
  --new_repo_id me/task_rel \
  --operation.type recompute_stats \
  --operation.relative_action true \
  --operation.chunk_size 50

# train the dataset whose stats you just recomputed
lerobot-train --dataset.repo_id=me/task_rel --policy.type=pi05 \
  --policy.use_relative_actions=true

Symptoms and what they actually mean

Normalisation bugs do not announce themselves. They arrive disguised as model problems, which is why people spend a day tuning learning rates first. This table maps what you see to what to check. Isaac-GR00T's own fine-tuning guide lists the same class of symptom, attributing an exploding or NaN loss to action and state normalisation rather than to a model bug.

The fifth row is the one worth being careful about, because it is the case where statistics are not to blame. Generalisation failure looks superficially similar and has nothing to do with normalisation; the page on policies that only work in one setup covers that separately. The full list of failure modes and their fixes is at /fix.

A five-line check before you rent a GPU

You do not need any of the training stacks installed to look at a stats file. It is JSON. The check below takes seconds and catches most of what this article describes.

import json, numpy as np

s = json.load(open("meta/stats.json"))["action"]
mean, std = np.array(s["mean"]), np.array(s["std"])
lo, hi = np.array(s["q01"]), np.array(s["q99"])

print("mean :", np.round(mean, 2))
print("std  :", np.round(std, 2))
print("span :", np.round(hi - lo, 2))
print("degenerate dims:", np.where(hi - lo < 1e-6)[0])
print("looks relative:", bool(np.all(np.abs(mean) < 5) and np.all(std < 20)))

Where none of this helps

Correct statistics are necessary and nowhere near sufficient. If your demonstrations are inconsistent, if the camera moved between recording sessions, or if you have 20 episodes when the policy needs 50, a perfect stats file changes nothing. Normalisation bugs are worth ruling out early precisely because they are cheap to rule out, not because they are the most common cause of a bad policy.

It is also worth being clear about what the platform does and does not do for you here. AY-Robots runs the trainers and rents the GPUs; it does not expose a normalisation-mode selector, and it cannot tell you whether your action column is absolute or relative any more than the file itself can. And on the serving side there is a hard physical limit that no amount of preprocessing fixes: the control loop is 20 to 485 ms per action step depending on the model, so inference latency over the public internet turns a working policy into a hesitant one. Remote inference is viable for slow pick-and-place and not for fast reactive motion.

Related reading

If you are earlier in the pipeline, collecting high-quality VLA training data covers what to record in the first place, and the full SO-100 guide covers build, teleoperation and training end to end. For the model side, the VLA overview explains what the action head is doing with those normalised numbers. If you are still choosing, GR00T N1.7 against Pi0.5 compares them directly, and the arena has 85 models with 332 benchmark results, each value linked to its source.