build(libero): robosuite 1.5.2 + mink override for RoboCasa coexistence

[shuheng-liu]

What this does

Bumps the libero extra from robosuite==1.4.0 to robosuite==1.5.2 and adds a [tool.uv] override-dependencies entry for mink, so LIBERO can share a single venv with RoboCasa (which requires robosuite >= 1.5). Pairs with the LIBERO fork's robosuite-1.5 port (shuheng-liu/LIBERO#3, merged to master). 🗃️ Feature

• robosuite==1.4.0 -> robosuite==1.5.2 in the libero extra; uv.lock regenerated (libero advanced to the merged master commit, mink resolves to 0.0.13).
• override-dependencies = ["mink>=0.0.10,<0.1"]: robosuite 1.5.2 hard-pins mink==0.0.5, which caps numpy<2 and would break OpenTau's numpy-2 stack (core rerun-sdk, the urdf extra, LIBERO itself). mink is only used by robosuite's GR1 whole-body-IK controller (imported under a try/except in robosuite/__init__.py), never on LIBERO's OSC_POSE/Panda path; mink 0.0.10+ drops the cap while still needing only mujoco>=3.1.6 (no mujoco bump).

How it was tested

• uv lock resolves cleanly (273 packages; robosuite 1.5.2, mink 0.0.13).
• On a CUDA box with EGL: a real LIBERO OffScreenRenderEnv builds, resets, steps a 7-D action, and renders both cameras on robosuite 1.5.2; control_freq threads through and action_dim == 7.
• End-to-end sim-eval parity: a pi0.7-PaliGemma low-level checkpoint on LIBERO-goal (10 tasks x 8 ep = 80 episodes) scored 18.75% (15/80) on the robosuite-1.5 stack vs the 21.25% (17/80) robosuite-1.4 baseline for the same checkpoint — within the expected run-to-run band, confirming the migration is behaviorally benign (sim stack preserved).

How to checkout & try? (for the reviewer)

uv sync --extra dev --extra libero

# LIBERO real-sim env build on robosuite 1.5.2 (needs a CUDA box + EGL):
LIBERO_CONFIG_PATH="$(pwd)/.github/assets/libero" MUJOCO_GL=egl \
  pytest -m gpu -n 0 tests/envs/test_libero_control_freq.py

Checklist

• I have added Google-style docstrings to important functions and ensured function parameters are typed.
• My PR includes policy-related changes.
  • If the above is checked: I have run the GPU pytests (pytest -m "gpu") and regression tests.

Note: Before submitting this PR, please read the contributor guideline.

[claude]

[claude-review] summary for commit b2f6477

Reviewed the robosuite==1.4.0 -> 1.5.2 bump and the mink numpy-2 override. This is a dependency-only change (pyproject.toml + uv.lock); no source changes.

Verified against the regenerated uv.lock:

• numpy stays at 2.2.6 — the mink>=0.0.10,<0.1 override successfully drops robosuite's mink==0.0.5 -> numpy<2 cap, preserving the numpy-2 stack (rerun-sdk / urdf extra / LIBERO).
• mujoco resolves to 3.4.0, satisfying both libero's >=3.3.5 and mink's >=3.1.6 — no mujoco bump required, as the PR states.
• mink resolves to 0.0.13; new transitive deps (qpsolvers, daqp, quadprog) are numpy/scipy-unconstrained and numpy-2-compatible.
• OpenTau's only direct robosuite API use is robosuite.utils.transform_utils.quat2axisangle (a stable util), exercised by the described end-to-end LIBERO sim-eval parity run.

The migration is well-validated: clean uv lock, a real OffScreenRenderEnv build/reset/step on robosuite 1.5.2, and sim-eval parity (18.75% vs 21.25% baseline, within run-to-run band). The controller-API change is absorbed by the paired LIBERO fork (shuheng-liu/LIBERO#3).

No blocking issues found.

Notes (non-blocking):

• override-dependencies is global to the resolution, not scoped to the libero extra. Harmless today (mink is only pulled transitively via robosuite, which is libero-only), but worth being aware of if another dep ever needs a different mink — uv has no per-extra override, so this is the correct mechanism.
• robosuite 1.5.2 now declares pytest as a runtime dependency, so the libero extra pulls pytest into non-dev envs. Upstream's choice, no action needed.