Add Task Program support for rigidized articulations

[yuecideng]

Stack

• Base: xinyi/atomic03
• Depends on: Support PickUp on articulated Rubik's cube asset #632
• Followed by: none

Description

This PR extends #632 so articulation-backed objects that are rigidized at their root can be used by configured Task Programs.

It:

• exposes rigidized articulations through SceneObjectRef and configured scene bindings;
• validates that the articulation has a floating root and coincident locked joint limits before treating it as an object;
• bounds author-controlled joint and transform tolerances so they cannot disable rigidization safety checks;
• proves configured joint-limit coincidence with a fixed internal epsilon;
• derives root-frame, link-scoped grasp geometry for atomic pick/place execution;
• rejects configured collision roles without planner-ready compound geometry, and rejects link-only meshes in HandOver and CoordinatedPickment;
• registers the published demo/RubiksCube.zip bundle for automatic asset resolution;
• applies the configured top_turn: [0, 0] lock with asset_physics_mode: overlay;
• adds a Native Task Program Rubik's cube pick-and-place example at TaskProgramRubiksCubePickPlace-v1, based on the repeated pick/place task configuration;
• documents the configuration contract and public integration APIs.

Dependencies: #632 (xinyi/atomic03). This PR should be reviewed and merged after that PR.

Current scope

Configured rigidized articulations support whole-object Pick/Place using a selected link as the grasp region. Their collision_role must remain none until physical compound collision geometry can be exported to a planner. HandOver and CoordinatedPickment reject link-scoped grasp meshes because their whole-object shape analysis would otherwise use only that link.

joint_position_tolerance and link_transform_tolerance may only tighten their safe maxima (1e-3 and 1e-5). Configured joint-limit coincidence uses a fixed 1e-6 safety epsilon and cannot be weakened by configuration.

Type of change

• New feature (non-breaking change which adds functionality)

Screenshots

Not applicable; this change adds runtime/configuration support and an executable task example.

Validation

• black .
• Latest focused Atomic Skill, Task Program, package-data, catalog, and CLI tests: 557 passed
• Earlier branch-wide full test suite: 5271 passed, 184 skipped, 66 deselected
• python docs/scripts/check_api_docs.py: 2268/2268 public APIs documented
• Sphinx dummy build: succeeded; existing repository warnings only
• Project-context checks: passed; atomic-actions and task-programs guidance updated for the scope boundary and tolerance contract
• Task Program inspector: TaskProgramRubiksCubePickPlace-v1 passed with 3 segments and 6 calls
• Latest Native physical run: environment initialized, all 3 segments / 240 steps executed, and 1 episode saved
• Stack synchronized: PR Support PickUp on articulated Rubik's cube asset #632 now contains the same origin/main revision, and this PR is again a focused 38-file upper layer

Native qualification command:

embodichain run-task --gym_config \
  embodichain_tasks/configs/tasks/manipulation/rubiks_cube_pick_place/task.ur5.yaml

Checklist

• I have run the black . command to format the code base.
• I reviewed affected documentation and agent context, updated it where needed, or explained why no update was needed.
• Public API changes are reflected in the API docs (python docs/scripts/check_api_docs.py), if applicable
• I have added tests that prove my fix is effective or that my feature works
• Dependencies have been updated, if applicable.

[greptile-apps]

Confidence Score: 4/5

The PR is not yet safe to merge because rigidized articulation objects still cannot be used with supported object settling or position-validation policies.

Findings

1.  Rigidized objects bypass policies ▶

Fix with agent prompt

### Issue 1
embodichain/lab/task_program/integrations/simulation/bindings.py:768-770
Rigidized articulations are declared as ordinary `SceneObjectRef`s, but `SimulationSegmentPolicyPort` does not add them to its native settle-target or object-observation maps. As a result, a valid Task Program that applies `wait_stable` or `object_near_target` to one of these objects fails with “no explicit native dynamic/rigid-object binding” instead of running the policy or validator. These bindings need to be exposed to the policy port through their native articulation handles.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

This PR adds Task Program support for treating locked, floating articulations as semantic objects.

• Adds validated root-frame grasp geometry derived from a selected articulation link.
• Extends scene registries, configured bindings, and composition validation for rigidized articulations.
• Restricts unsupported collision and whole-object geometry use.
• Registers the Rubik’s Cube asset and adds a configured UR5 pick-and-place example.
• The latest changes bound author-configurable tolerances and use a fixed epsilon for physical joint-limit coincidence.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  YAML[Configured rigidized articulation] --> Decode[Strict binding decoder]
  Decode --> Validate[Validate floating root and coincident limits]
  Validate --> Registry[Publish SceneObjectRef]
  Validate --> Geometry[Transform selected link mesh into root frame]
  Geometry --> Affordance[Link-scoped grasp affordance]
  Registry --> Pick[Task Program Pick / Place]
  Affordance --> Pick
  Registry -. unsupported .-> Policy[Settling and object-target policies]

Loading

_{Reviews (5) · Last reviewed commit: "Merge remote-tracking branch 'origin/xin..."}

[greptile-apps]

Rigidized objects bypass policies

Rigidized articulations are declared as ordinary SceneObjectRefs, but SimulationSegmentPolicyPort does not add them to its native settle-target or object-observation maps. As a result, a valid Task Program that applies wait_stable or object_near_target to one of these objects fails with “no explicit native dynamic/rigid-object binding” instead of running the policy or validator. These bindings need to be exposed to the policy port through their native articulation handles.

Knowledge Base Used: Task program workflows

Prompt To Fix With AI

This is a comment left during a code review.
Path: embodichain/lab/task_program/integrations/simulation/bindings.py
Line: 759-761

Comment:
**Rigidized objects bypass policies**

Rigidized articulations are declared as ordinary `SceneObjectRef`s, but `SimulationSegmentPolicyPort` does not add them to its native settle-target or object-observation maps. As a result, a valid Task Program that applies `wait_stable` or `object_near_target` to one of these objects fails with “no explicit native dynamic/rigid-object binding” instead of running the policy or validator. These bindings need to be exposed to the policy port through their native articulation handles.

**Knowledge Base Used:** [Task program workflows](https://app.greptile.com/dexforce/-/custom-context/knowledge-base/dexforce/embodichain/-/docs/expert-program-workflows.md)

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.