grootn17-lora-so101-eraser-tier1

LoRA adapter for nvidia/GR00T-N1.7-3B, trained on a single SO-ARM101 manipulation task (90 episodes, "Place the white eraser on the red square"). Produced with the gr00t-n17-lora wrapper.

Status: demo / verification only. This adapter exists to demonstrate that the wrapper successfully restores LoRA support on GR00T N1.7. It is trained on a deliberately small, single-task dataset and is not a production-quality skill. See "Limitations" below.

Adapter configuration

Field	Value
Base model	nvidia/GR00T-N1.7-3B
LoRA rank	32
LoRA alpha	64
LoRA dropout	0.05
Target modules	attention (q_proj, k_proj, v_proj, o_proj, to_q, to_k, to_v, to_out.0) and MLPs (gate_proj, up_proj, down_proj, net.2, 0.proj)
modules_to_save	state_encoder, action_encoder, action_decoder, position_embedding, vlln, vl_self_attention
Adapter size on disk	~2.2 GB

Note on adapter_config.json. The task_type field is intentionally absent. PEFT serialises task_type=None by omitting the key, and the Hub's metadata validator displays a "Configuration Parsing Warning" because its schema expects a known string here. This is cosmetic: PeftModel.from_pretrained loads a generic PeftModel when task_type is unset, which is the correct path for GR00T's dict-input forward. Setting it to an NLP enum value such as FEATURE_EXTRACTION would force an input_ids / attention_mask keyword signature on the base model and break inference. See the wrapper's docs/debugging_journey.md § Blocker 2 for context.

Usage

Install the wrapper and run the four verification checks:

git clone https://github.com/jinnymo/gr00t-n17-lora
cd gr00t-n17-lora
pip install -r requirements.txt

huggingface-cli download nvidia/GR00T-N1.7-3B --local-dir models/GR00T-N1.7-3B
huggingface-cli download dongyoonkim/grootn17-lora-so101-eraser-tier1 \
  --local-dir adapter

python verify_inference.py --base models/GR00T-N1.7-3B --adapter adapter

Expected: all four checks pass (trainable percentage, non-zero LoRA-A weights, on-disk size, and a non-trivial forward output difference between adapter-on and adapter-off).

Training data

Single SO-ARM101 robot, single wrist camera (Innomaker U20CAM-1080P, 640x480 @ 30 fps), 90 demonstrations of placing a white eraser onto a red square. All trajectories are successful demonstrations; no recovery behavior is included.

Dataset: dongyoonkim/so101-eraser-90ep-wrist.

All 3D-printed parts use the official LeRobot STL files.

Training procedure

Hyperparameter	Value
Optimizer	paged_adamw_8bit (bitsandbytes)
Learning rate	1e-4
LR schedule	cosine, warmup ratio 0.05
Batch size (global)	16
Steps	15,000
Gradient checkpointing	enabled
Hardware	single RTX 3090 Ti (24 GB)
Wall time	~2.3 h
Final training loss	0.029 (best 0.0181 near step 14940)

Open-loop evaluation

Mean absolute joint error (MAE), evaluated on three held-back trajectories from the same dataset:

Checkpoint step	Avg MAE (deg)	Avg MSE
3000	3.846	36.51
6000	2.803	25.57
9000	2.347	20.15
12000	1.860	12.73
15000 (this adapter)	1.661	10.85

For reference, on the same dataset and protocol:

• A full fine-tune of the same base reaches 1.30 deg MAE (model size ~15 GB).
• A LoRA-attention-only baseline (no modules_to_save, no MLP targets) reaches 6.13 deg MAE.

Limitations

• Single-task, small-dataset baseline. Real-robot success rate is approximately 40% on this task. The same dataset caps a full fine-tune at ~46%, so most of the remaining gap is dataset-bound, not adapter-bound.
• Narrow training distribution. All 90 episodes are successful demonstrations; the policy has not been trained to recover from out-of-distribution states.
• Specific embodiment. SO-ARM101 with a single wrist camera. Other cameras / embodiments will require a different modality config and re-training.
• Demo / verification artifact, not a production skill.

License

Apache License 2.0.