Reproduce RoboTwin

policy/ contains the single KinRT implementation, and script/ contains the RoboTwin evaluation overlay. The release does not contain the complete simulator, task assets, or the 800-episode training dataset.

Install RoboTwin 2.0 and its simulator assets according to the upstream project. Before applying the policy overlay, verify that the checkout contains envs/, task_config/, script/, and the embodiment assets required by the selected tasks.

export ROBOTWIN_ROOT=/work/RoboTwin-kinrt
test -d "$ROBOTWIN_ROOT/envs"
test -d "$ROBOTWIN_ROOT/task_config"
cp -a /path/to/KinRT/policy/. "$ROBOTWIN_ROOT/policy/"
cp -a /path/to/KinRT/script/. "$ROBOTWIN_ROOT/script/"
cd "$ROBOTWIN_ROOT/policy/pi05"
uv sync --frozen

FULL and LoRA use this same overlay. Use separate experiment names and output directories, and preserve the upstream RoboTwin commit and simulator asset version in the experiment record.

The reported comparison uses 162,545 frames from 800 episodes. The active config expects three images, state, action, and prompt fields after repacking.

Replace the placeholder repo_id="demo_mixed_repo" with the local LeRobot dataset identity. Verify episode count, frame count, field shapes, action units, and global index coverage.

Generate and verify the K=4 supervision using the KinRT method procedure, then point the selected config to the local dataset, labels, base weights, and writable output. Keep one config name from normalization through serving.

cd "$ROBOTWIN_ROOT/policy/pi05"
uv run python scripts/compute_norm_stats.py --config-name kinrt_full
uv run python scripts/train.py kinrt_full --exp-name robotwin_kinrt_full

cd /work/RoboTwin-kinrt-lora/policy/pi05
uv run python scripts/compute_norm_stats.py --config-name kinrt_lora
uv run python scripts/train.py kinrt_lora --exp-name robotwin_kinrt_lora

The audited settings are 10,000 steps, global batch 32, EMA disabled, supervised router coefficient 0.05, and inverse-square-root balanced sampling. FULL uses one FSDP device in the retained config; LoRA uses two. Report any resource override.

Create deploy_policy.yml from the included example. Resolve every placeholder before starting the server.

policy_name: pi05
task_name: <task-module-name>
task_config: <clean-or-random-config>
test_num: 100
train_config_name: kinrt_full
model_name: robotwin_kinrt_full
checkpoint_id: 10000
checkpoint_dir: /checkpoints
model_server_host: <reachable-server-host>
server_bind_host: 0.0.0.0
port: 8001
eval_result_root: ./eval_result
router_info_root: ./eval_result/router_info
record_router_info: true

Local evaluation

cd "$ROBOTWIN_ROOT/policy/pi05"
bash eval.sh <task_name> <task_config> kinrt_full \
  robotwin_kinrt_full 0 0

Remote evaluation

cd "$ROBOTWIN_ROOT/policy/pi05"
bash serve_remote_model.sh deploy_policy.yml

cd "$ROBOTWIN_ROOT/policy/pi05"
MODEL_SERVER_HOST=<reachable-server-host> \
  bash eval_remote.sh <task_name> 0

The server creates an independent policy session for each socket connection. LORA additionally uses an explicit eval_done acknowledgment, a 300-second client socket timeout, episode-level exception isolation, and checkpoint identifiers in responses. These are robustness differences, not changes to KinRT.

Resolve the exact task module and task-config filenames from the compatible RoboTwin checkout. The paper reports these eight task labels under both clean and randomized conditions.

Hand block

Hang mug

Move can

Open laptop

Place shoes

Place on pad

Rotate QR code

Turn switch

• FULL or LoRA config name, source commit, and all config overrides.
• Dataset identity, frame count, label digest, norm-stat asset ID, and base checkpoint.
• Fine-tuned experiment name, checkpoint step, and parameterization.
• RoboTwin commit, task module, task config, simulator assets, condition, and seed set.
• Requested, completed, successful, failed, and transport-aborted episode counts.
• Evaluation result directory and router telemetry directory.