groot-n17-relative-joints-all10-30k

GR00T N1.7 — relative actions, joint space

Fine-tune of nvidia/GR00T-N1.7-3B on all ten L5vel/* datasets, with actions expressed relative to the observation state at the start of each chunk. Step 30K of 30K — the full run.

Held-out loss

5% of episodes per task are held out (75 of 1499 episodes, all 11 tasks).

Still decreasing at 30K, and the run covers only 0.66 epochs of the mixture, so this checkpoint is undertrained rather than converged. Longer training is the obvious next step.

Do not compare this number to the pi05-relative-* repos. Both are MSE on the flow-matching velocity, but the normalisation differs: pi05 uses QUANTILES (q01/q99), GR00T N1.7 uses per-horizon min/max of the relative offsets. On this mixture the min–max span is 3.0x the q01–q99 span (median) on the arm dims and 5.0x (up to 49.7x) on the base dims, so GR00T's targets live in a compressed space and its loss is smaller by roughly the square of that factor for reasons that have nothing to do with fit quality.

Action representation

use_relative_actions=true with relative_exclude_joints=["gripper"]:

action[t+k] -= observation.state[anchor]     for all dims EXCEPT gripper
gripper                                       absolute (it is a command, not a pose)

Action dim 10: joint1..joint6, gripper, base_x, base_y, base_yaw — 9 of 10 dims relative, gripper absolute.

Normalisation uses GR00T's native per-horizon relative statistics, computed from this mixture's own relative offsets (a separate min/max per chunk position, shape [40, d]) and baked into policy_preprocessor.json. The checkpoint is self-contained: it does not need the training data or the base model's statistics.json to normalise correctly.

Chunk size is 40, not 50

The run requested chunk_size=50 to match the pi05 arms, and GR00T N1.7 overrode it to 40: GrootConfig.__post_init__ remaps 50 as a legacy N1.5-era default, and the action head's delta_indices are clamped to the N1.7 horizon of 40 regardless. So the lookahead is 0.8 s at 50 fps rather than pi05's 1.0 s. n_action_steps=10 (0.2 s executed per replan) is unchanged, so the control cadence still matches.

Training data

11 language-conditioned tasks, 1499 episodes, 3,089,476 frames (17.2 h at 50 fps), one u850 arm on a mobile base, three cameras (left / right / wrist).

The mixture is skewed: the four largest tasks are ~82% of frames. Sampling is uniform over frames, so it is not rebalanced.

Shipped training metadata (meta/)

meta/info.json and meta/stats.json are the training dataset's own files, byte for byte. They are here so a deployment-side fingerprint guard can bind this checkpoint to real column names and real statistics instead of inferring them. The datasets (all10-multitask-eef-merged-v30) were merged locally from the ten L5vel/* sources and never pushed, so the repo_id in train_config.json 404s on the Hub.

The statistics bind exactly. The preprocessor step groot_n1_7_pack_inputs_v1 carries config.raw_stats with three modalities -- state, action, relative_action. The first two are this dataset's absolute statistics, copied verbatim. Concatenating the groups in modality order (single_arm, gripper, single_arm_2) and casting both sides to float32 reproduces stats.json exactly, for min, max, mean and std alike:

action            float32-cast exact = True
observation.state float32-cast exact = True

Compare in float32, not float64: that is the storage precision on the checkpoint side, and a float64 comparison leaves residuals up to 5.8e-08 relative on some columns.

relative_action is the modality with no on-disk counterpart. Those per-horizon [40, d] min/max are computed at training time from the relative offsets and never written as a dataset.

Two traps in these files

1. names is the grouped v3 form, {"motors": [...]}, not a flat list, so list(names) yields ["motors"] -- one name for 10 columns. Flatten it (lerobot.utils.feature_utils.flatten_feature_names). These files are shipped unmodified on purpose, so the flattening is the reader's job.
2. The dataset carries a second, unrelated action feature. Alongside the 10-dim joint-space action this checkpoint was trained on, meta/info.json describes a 13-dim action.eef (eef_x ... eef_yaxis_z, gripper, base_*) recorded from the same episodes, and the checkpoint's output_features lists both. Here the dims differ (10 vs 13) so they are easy to tell apart, but a binding should still name action explicitly rather than take the first action-like feature it finds.

Recipe

Loading

from lerobot.policies.groot.modeling_groot import GrootPolicy
policy = GrootPolicy.from_pretrained("maskjp/groot-n17-relative-joints-all10-30k")

base_model_path in config.json points at nvidia/GR00T-N1.7-3B; the architecture is rebuilt from there and the fine-tuned weights come from model.safetensors in this repo.

License

NVIDIA License, inherited from the base model — research and evaluation use only (section 3.3). A complete copy ships as LICENSE in this repo, as section 3.1 requires.

Related

• maskjp/groot-n17-relative-eef-all10-30k — the same run in end-effector space.
• maskjp/pi05-relative-joints-all10-full-ft-100k — pi0.5 on the same mixture and the same relative-action scheme. See the loss caveat above before comparing numbers.