DexLab project & documentation#

Contact-rich robotics, beyond rigid-body simulation.

DexLab is a physics-centric research platform for robot manipulation involving contact, deformation, and material separation.

简体中文 · Experiments · Research protocol · Quick start · Architecture · Paper guide

Native commands, contact readback, independent scoring, offline evidence, and several contact experiments are available today. Remote model execution, a public leaderboard, and cross-task unified conclusions are still being built.

Start here#

What would you like to do?	Suggested entry
Understand what dexterous-hand simulation studies	What are we discussing when we discuss dexterous manipulation simulation? (Chinese original): the full six-layer review, paper filters and repository comparison, with an October supplement. English reading companion.
Inspect experiments, rescore evidence or reproduce a task	Experiments → Quickstart; inspect existing evidence with the GPU-free wiping rescore.
Understand contact failures and backend differences	Failure root-cause atlas → Per-configuration audit → Solver configuration roles → Full results.
Integrate a model or understand evaluation rules	Model-evaluation protocol; remote execution and public leaderboards are not yet complete.
Read related research	Newton topic guide → Complete bibliography; find other reading in References.

Research vision: Simulation–Learning Co-evolution#

Models expose simulation gaps; more trustworthy simulation then produces better models.

The near-term center is a Physics Research Platform: contact, deformation, and material separation become observable, attributable, and rescorable experiments. The long-term loop feeds model failures back into simulation, then uses improved simulation to train and evaluate models.

Architecture#

Scripts, policies and models connect to environments through action adapters and controllers, with observations fed back to the system under test. Native state and contact records support independent scoring, and diagnosis guides the next experiment.

This conceptual architecture uses task thumbnails to illustrate task categories. See the coverage matrix for implemented and validated coverage; the generative backend is a research candidate. Real experiment recordings and evidence appear below.

Why DexLab?#

When a robot policy fails in simulation, we see one failure. It may come from the policy, controller, scene, contact discretization, material model, or numerical solver.

When a robot fails in simulation, is it the policy that fails, or the physics we trusted?

DexLab makes these questions testable:

Under matched geometry, load, and control, does the contact model change whether an object is held, slips, or releases?
Do smaller timesteps, finer meshes, or more iterations approach the physical answer, or merely change numerical behavior?
When can a robot grasp a cloth, and when can it actually fold, transfer, and release it?
How should cutting, friction, and material separation be recorded and accepted beyond a video?
Does a policy or API ranking survive replacement of the physics backend?

Research areas#

Area	Research question	Current entry
Contact physics	Are normal response, friction, retention, sliding, impulse, and release independently checkable?	Contact mechanics · Hold and slip
Deformable objects	Can grasp, sag, stretch, layer contact, and release be scored separately?	Cloth comparison · Replay rendering
Topology-changing interaction	How should cutting and material separation record contact, connectivity, and material response?	Cutting and pushing
Cross-backend evaluation	When can engines, integrators, and solvers be compared under matched physical inputs?	Engines · Selection
Policy and API evaluation	How can model, adapter, and invalid-physics failures be separated?	Evaluation · RoboAPI adapter

Experiment previews#

These animations come from DexLab simulation recordings or recorded-state replays. Every result applies only to its reported version, material assumptions, and acceptance protocol.

Grasp and slip resistance	Sponge wiping and grasp dependence
Under the same control, synthetic torsional contact reduces two-second hold drift from 2.734 mm to 1.025 mm.	Assisted retention passes 3/3; no assistance gives 0/3, with final cleaning around 95.47% / 39.92%.
Deformable manipulation	Cutting and topology change
The robot can pinch and move a cloth patch, but complete folding still fails: the current record reaches 12.55% edge strain against a 5% limit.	Continuous cutting and blade-face pushing change the simulated topology; the full report records contact force, material separation, and retained failures.
RoboDojo: neighbor-amplified roll-out	RoboDojo: pure shallow-grip loss
The close command remains active, but neighbor/shelf interaction amplifies an upper-edge pinch; the slice falls after bilateral normal load reaches zero.	No pre-release external impact occurs. During lifting the slice rotates, edge margin falls from 14.41 to 2.87 mm, and only then does contact disappear.

Experiments and findings#

Experiment	Condition	Result and meaning
Contact representation changes the grasp verdict	Wuji sphere pinch under matched control	`condim=3` drifts 2.734 mm, above 2 mm; `condim=4` reaches 1.025 mm.
Wiping success depends on grasp assistance	RoboSimStudio `wipe_the_bar`	Assisted 3/3, cleaning around 95.47%; unassisted 0/3, around 39.92%.
Surface discretization changes the failure boundary	Same cylinder, mass, force command, and step; only meshing changes	`256 → 1,024 → 4,096` triangles gives peak penetration 2.267 → 0.858 → 0.481 mm.
Grasp behavior can depend on the backend	Apple-stem grasp, ten paired scenes	Current defaults pass MuJoCo 1/10 and SuperDex 10/10; smaller steps do not monotonically reduce penetration.
A stable cloth grasp is not a fold	OpenArm + Wuji with passive cloth	Pinch, lift, and release pass; complete folding fails on strain, residual contact, and final geometry.
A close command is not a valid grasp	Two local events from external RoboDojo `make_toast` records	Bilateral normal impulse falls from about 0.25 N·s to near zero; one has a neighbor impulse, while rotation and edge-margin loss precede collapse in the other. Fix grasp geometry before testing material readback and compliance.

Together, these results show why a success video is insufficient: material models, contact response, and downstream policy transfer must be checked separately.

Full experiments · Failure root-cause atlas · All results and failures · Research findings

Play the claw machine#

Move with the arrow keys, WASD or on-screen buttons. Line up a toy and press Space or Drop claw. The three-finger claw descends, closes, lifts and returns to the gold chute. A prize counts only after it actually lands and settles in the bin. After you drop, Newton, CG and PGS run from the same state with elliptic friction cones, implicitfast and 2 ms steps. Scrub the shared replay, slow it down, or change the iteration cap and repeat the original grab. Re-aiming continues the Newton cabinet.

Open the claw machine in a larger view

MuJoCo computes contact locally in your browser. One fixed mix of 30 prizes covers all 16 Nai-family characters, with no lineup selector. Larger toys settle under gravity into a pile, and the claw uses the measured surface height at drop. The deep-purple cabinet has rose lighting, moon/star trim and a matching cat-ear claw. Click a portrait to inspect a mesh up close. They use locally generated textured meshes and approximate rigid collision shapes, with no attachment or random win. This is not deformable-plush or hardware validation. The guide below the game explains all three solvers and explicit, semi-implicit and implicit integration. Agreement is a valid result; a successful catch alone does not establish physical accuracy.

The page prefers local WebGPU, falls back to WebGL 2 when needed and displays the actual backend. Physics and replay run in a separate worker. Phones use capped rendering resolution and frame rate, with lighter meshes and textures. All three worlds retain the same collision models, 2 ms step and iteration budget; simulation time can run slower than wall time on a busy device.

Quick start#

On Linux x86_64 with uv, run apple-stem grasping:

git clone https://github.com/huangkiki/Dexlab.git
cd Dexlab
bash scripts/setup.sh --mujoco-profile historical-3.11.0
bash demos/apple-stem-grasp/run.sh \
  --backend mujoco \
  --output demos/apple-stem-grasp/runs/first-mujoco
.venv/bin/python demos/apple-stem-grasp/src/verify_sdf_grasp.py \
  demos/apple-stem-grasp/runs/first-mujoco

The verifier writes summary.json; when all checks pass, passed: true. Fourteen seconds is simulation time, not expected wall time. Add --headless without a display and use a fresh output directory.

To inspect the evidence chain without installing a simulator, start with Quickstart. Full dependencies and commands are on that page.

Research roadmap#

Contact and material response: calibrate stiffness, damping, friction, and real measurements before ranking engines.
Deformable manipulation: extend from pinch, transfer, and release to auditable folding geometry, self-contact, and material-point tracking.
Topology-changing tasks: define continuous geometry, contact-force, and outcome criteria for cutting, separation, and adhesion.
Cross-backend attribution: distinguish solver, integrator, collision geometry, precision, timestep, and framework wrapper.
Policy and neural backends: test whether API rankings and task conclusions transfer from native physics to learned world models.
Co-evolution: after evidence supports it, use model failures to improve simulation and improved simulation to train and evaluate better models.

CHORD migration preparation: fixed task cards, asset preflight and finite upstream command preparation are available; native training/recording/scoring remain pending (0/3 migrated). Prepare a task.

Ecosystem backend: Uranus#

Uranus is a D-Robotics robot video world model that generates multi-view observations from future qpos, cameras, and robot geometry. It is currently a documented candidate generative backend, not a verified physics backend.

The integration path is RoboAPI → IK/controller → qpos → Uranus → RGB → task scorer. Uranus supplies visual observations; it does not provide native contact state, task success, or physical truth. Read the full introduction, candidate tasks, and evidence boundary.

Evidence and boundaries#

Task success is not physical truth; numerical consistency is not real-world accuracy.
A simulation pass is not hardware success; a rendered replay is not visual control.
Engine coverage differs by task, material model, and acceptance condition; DexLab does not publish a universal engine ranking.
Failures, invalid runs, and missing readouts remain visible; thresholds are not relaxed and counterexamples are not deleted.
Uranus and remote model evaluation are candidates; an upstream paper or interface does not establish a DexLab reproduction.

Documentation and citation#

Experiments · Findings · Solver roles · Coverage · Contributing · Current Work

No companion paper is published yet. When citing the repository, use its URL and a specific commit or release rather than attributing unpublished paper results.

@software{dexlab2026,
  author  = {DexLab contributors},
  title   = {DexLab: A Physics-Centric Research Platform for Contact-Rich Robot Manipulation},
  year    = {2026},
  url     = {https://github.com/huangkiki/Dexlab}
}