x-square-robot/wall-oss-1.0-lite-robodojo

WALL-OSS 1.0 Lite — RoboDojo

A Qwen3.5-based vision-language-action (VLA) policy from the WALL-OSS family, fine-tuned on RoboDojo demonstrations and released for evaluation on the RoboDojo benchmark through XPolicyLab.

• Predicts a 32-step native end-effector-pose action chunk for the dual-arm arx_x5 robot (EE poses + gripper states), refined by a residual refiner (four chained passes).
• Keeps a keyframe memory: it re-reads a sliding window of recent head-camera frames and decides which ones to retain, which makes the long-horizon and memory-dependent RoboDojo tasks reachable.

Files

checkpoint/
├── model.safetensors        # F32 weights (cast to bf16 at load time, except normalisation layers)
├── config.json              # model config (Qwen3_5ForConditionalGeneration + vla_config)
├── config.yml               # wall-x policy config used by the serving code
├── normalizer_action.pth    # action normaliser
├── normalizer_propri.pth    # proprioception normaliser
└── global_step.pth
assets/processor/            # tokenizer, chat template, processor config

Usage

The serving code lives in wall-x; until X-Square-Robot/wall-x#128 is merged, install it from the branch the published numbers were produced with:

git clone -b starrick/robodojo-serving https://github.com/StarrickLiu/wall-x.git
git -C wall-x checkout 39fa65b9c9e95b0316db0fc9dbe41211e3a0d4cc
MAX_JOBS=8 pip install --no-build-isolation -e wall-x    # compiles the fused CUDA operators

hf download x-square-robot/wall-oss-1.0-lite-robodojo --local-dir wall-oss-1.0-lite-robodojo

Then run it with the XPolicyLab WallX adapter (policy/WallX), pointing it at the checkpoint/ directory:

cd XPolicyLab/policy/WallX
WALLX_CHECKPOINT=/path/to/wall-oss-1.0-lite-robodojo/checkpoint \
  bash eval.sh RoboDojo swap_blocks wall-oss-1.0-lite-robodojo arx_x5 ee 0 0 0 <policy_conda_env> <eval_env_conda_env>

See the adapter README for installation details, pinned dependency versions, deploy.yml settings and full-benchmark runs. One server process uses about 19 GB of GPU memory with ten environments batched.

Limitations

• EE-pose actions for the arx_x5 embodiment only; joint action runs are rejected.
• Trained for the RoboDojo simulation benchmark; not validated on real robots.
• Batched and single-environment requests agree to bf16 batch-reduction precision, so num_envs changes individual rollouts, not the policy.