JACO2_STOW keyframe parks the fork inside the table-demo plate (7.6 mm penetration)

[siddhss5]

Symptom

In the table demo scene, the JACO 2 stow keyframe (from ada_assets) leaves the fork tine in contact with the plastic_plate collision mesh:

>>> robot.arm.check_collisions()
jaco2 arm: 1 contact(s)
  fork_tine <-> plastic_plate: 7.6mm
[('articutool/fork_tine', 'plate/plastic_plate', 0.007594)]

Verified at fresh-load with no physics steps, no user motion. The keyframe was designed before the table scene existed.

Why it matters

A robot starting in collision blocks any plan from succeeding — the planner reports AllStartConfigurationsInCollision. We hit this the first time we tried move_above from stow.

Workaround in place

The feeding demo (ada_mj/demos/feeding.py) declares initial_pose: "above_plate", and the demo loader applies that pose at construction. So launching uv run python -m ada_mj --demo feeding --viser does the right thing.

But:

• Users who do ADA() without a demo land in the bad state.
• Any future scene-bearing demo has to remember to override initial_pose.
• The stow keyframe is intrinsically wrong now — it doesn't represent a safe parked pose for any scene with a plate.

Recommended fix

Retune JACO2_STOW in ada_assets/src/ada_assets/jaco2.py so the fork tine clears the plate's xy region in the table scene with at least a few cm of headroom. The above_plate config we currently override to is one valid option; an "arm folded against the wheelchair back" pose might be more natural for a "parked" semantic.

After the fix, the feeding demo can drop the initial_pose override (the default stow would already be safe), or keep it as the natural starting pose for the demo's narrative.

Related

• Surfaced during ada_mj Demos: feeding demo + loader + CLI / console wiring (geodude pattern) #32 (feeding demos) — fix tracked separately so the demo could ship.