Downloads · 30 days
0
arunos728/pi05-rby1-assembletissue-chunk30-4gpu-b32-30k
pi05-rby1-assembletissue-chunk30-4gpu-b32-30k is a robotics model from arunos728. Use it for the robotics task on the model card, and read the license before you ship it in a product. The card lists the license as apache-2.0.
RLWRLD RB-Y1 bimanual platform finetune of pi0.5 (openpi PyTorch path). 30,000 steps on 4x H100, 7h 57m, final loss 0.0007.
Downloads · 30 days
0
Access
Public
Updated Sep 24, 2026
Parameters
3.6B
7.5 GB on disk
Likes
0
Public
Click a slice to open those files.
.safetensors7.5 GB · 100%
How the weights are stored.
BF163.5B · 97%
From the Hugging Face model README
RLWRLD RB-Y1 bimanual platform finetune of pi0.5 (openpi PyTorch path). 30,000 steps on 4x H100, 7h 57m, final loss 0.0007.
| base model | pi05_base (openpi JAX checkpoint converted to PyTorch) |
| steps | 30,000 |
| GPUs | 4x H100 80GB |
| batch size | 32 total across ranks (8 per GPU) |
| lr schedule | cosine decay, warmup 1,000, peak 5e-5, decay 5e-6 |
| optimizer | AdamW, grad clip 1.0 |
| EMA | none (unsupported on the PyTorch path) |
| action horizon | 30 (1.0 s at 30 fps) |
| action_dim | 54 (pi0.5 defaults to 32) |
| action representation | absolute joint targets, no delta transform |
RB-Y1 + Wuji hand (rby1m_wujihand2). 54-D absolute joint targets, grouped as:
right_arm_joints [0:7] right_hand_joints [7:27]
left_arm_joints [27:34] left_hand_joints [34:54]
action uses the same four groups as *_command_joints
No head joints, and the hands are 20-D each. State and action group identically here -- worth stating because the sibling OpenArm/RH56F1 checkpoints do not (there the action side splits head from arm while the state side folds them together). Do not carry that caveat across.
Cameras are a stereo ego pair, ego_left / ego_right, 320x180.
35,613 frames / 50 episodes at 30 fps, single task "Put the tissue roll onto the holder." Internal dataset, not public.
A companion run of the same task on the OpenArm/RH56F1 platform (28-D) exists with the same chunk, batch and step count, so the two robots can be read against each other.
pi0.5 defaults to action_dim=32, which sizes action_in_proj, action_out_proj and
state_proj. 54 does not fit, so this run raised action_dim to 54. The consequence,
measured rather than assumed -- the training log named exactly these and nothing else:
action_in_proj.weight checkpoint (1024, 32) -> model (1024, 54)
action_out_proj.weight checkpoint (32, 1024) -> model (54, 1024)
action_out_proj.bias checkpoint (32,) -> model (54,)
Those three started from random init; the PaliGemma backbone and the action expert body
loaded from pi05_base normally. Final loss landed at 0.0007, the same order as the
28-D sibling runs (0.0002-0.0003), so the cost appears small -- but it is a real
deviation from how the base model was pretrained and worth knowing before comparing.
Note that transforms.pad_to_dim only pads and never truncates, so a 54-D vector against
action_dim=32 fails loudly on shape rather than being silently cut.
base_0_rgb <- ego_left 320x180 -> 224x224
left_wrist_0_rgb <- ego_right
right_wrist_0_rgb <- zeros, masked out (this platform has no third camera)
model.safetensors (7.5 GB), metadata.pt, and the normalization statistics under
assets/. Optimizer state (13.5 GB) and intermediate checkpoints are not included.
The bundled statistics were checked for the std == 0 failure mode that openpi's float32
accumulator can produce (E[x^2] - E[x]^2 cancelling for dimensions far from zero with
tiny variance). This dataset is clean -- minimum std is 2.2e-02 for state and 2.7e-02 for
actions -- but if you regenerate them, check for zero-std dimensions before training.