ฯ€0.5-DROID fine-tuned on the bussing task

Fine-tuned from pi05_droid on Sombit/bussing_task_new (real-robot table bussing, "put the vegetables in the bowl"). Built to drop straight into the existing DROID deployment โ€” stock architecture, stock data config, stock DROID normalization statistics. Nothing custom to install.

Deploy

hf download <REPO_ID> --local-dir ./bussing_droid

# paste the TrainConfig from train_config_snippet.py into
# openpi/src/openpi/training/config.py
python scripts/serve_policy.py \
    --policy.config=pi05_droid_bussing \
    --policy.dir=./bussing_droid

In pi0_robot.yaml, point at this checkpoint and keep everything else:

policy_config:
  autoclass: examples.pi0.pi0.PizeroPolicy
  model_config:
    model_id: pi05_droid_bussing        # contains "droid", passes the assert
    checkpoint_dir: /path/to/bussing_droid
  flip_gripper: False                    # <-- MUST be False, see below
  action_space: joint_velocities         # unchanged

โš ๏ธ Set flip_gripper: False for this checkpoint

flip_gripper: True exists to convert this robot's gripper convention into DROID's for the stock pi05_droid model. This checkpoint was fine-tuned on the raw recorded values, so it already speaks the robot's convention โ€” 1.00 = open, ~0.3 = closed on an object (verified: all 38 episodes start at exactly 1.00 and dip to 0.26-0.30 at the grasp).

Leaving the flip on would invert the gripper twice over โ€” once on the observation fed to the model, once on the action sent to the arm โ€” so it would open on the object and close on empty air. With the flip off, input and output both match what the model was trained on.

Interface

Exactly the standard DROID contract โ€” no conversion step, unlike the previous end-effector-pose version.

observations observation/exterior_image_1_left, observation/wrist_image_left, observation/joint_position (7), observation/gripper_position (1), prompt
actions 8-d: 7 joint velocities (rad/s) + gripper position
action horizon 16
norm stats the original DROID statistics, reused (not recomputed)

Measured performance

All three checkpoints, identical protocol โ€” same 5 held-out episodes, same 48 samples, same 8-step horizon (the number his runner executes):

metric this (DROID stats) own stats ACT
velocity error (rad/s) 0.0187 0.0190 0.0203
beats zero-motion baseline 29.9% 28.9% 24.1%
gripper error 0.0073 0.0097 0.0349
motion ratio (1.0 = human) 0.921 0.928 0.940
joint error, 8 executed steps 0.0286 0.0289 0.0307
clipped by controller 1.8% 2.8% 2.1%

Best of the three on most metrics, though the two ฯ€0.5 variants are within a point of each other on everything โ€” effectively a tie. Both beat the ACT policy on the gripper channel by ~4ร—, which matters directly for whether a grasp closes at the right moment.

Beating a zero-motion baseline by ~30% is a modest margin; velocities in this data are small and smooth, which makes "command nothing" a strong baseline. Offline metrics cannot predict closed-loop task success โ€” that needs the robot.

Known limits

  • 33 episodes of a single task. Do not expect generalization to new objects, new layouts, or rephrased instructions.
  • Our joint velocities have ~5ร— smaller spread than DROID's average (std 0.03โ€“0.05 vs 0.15โ€“0.31) โ€” this teleoperation is slower and smoother than DROID's. State scales match well (0.6โ€“1.08ร—). The DROID normalization is reused per openpi's guidance, which means our actions occupy a compressed part of the normalized range.
  • Trained on data where the arm always starts from โ‰ˆ the same home pose (1 cm spread across all 38 episodes). Starting far from it is out of distribution.

Supersedes

An earlier upload trained absolute end-effector poses from pi05_base. That was the wrong action space for this stack โ€” JointVelocitiesAction(velocities= action[:7]) read those metres as rad/s โ€” and it could not reach objects. Do not use it.

Downloads last month

-

Downloads are not tracked for this model. How to track
Video Preview
loading