Concurrent plannign for bimanual arms

[dimos-bot]

Synced from DIM-854 by mustafa

[mustafab0]

Summary

ManipulationModule follows a plan → preview → execute flow that is single-threaded. With multiple arms (e.g. OpenArm bimanual), every plan call blocks the whole module for 5–15s, so a bimanual sequence pays planning latency twice before either arm moves. We want one ManipulationModule to manage as many arms as RAM allows, with plan / preview / execute runnable concurrently per arm.

Context

Planning state is already keyed by robot_name (_planned_paths, _planned_trajectories) — but plan_to_* calls self._planner.plan_joint_path(...) inline, so a second plan can't start until the first returns. execute is already async via ControlCoordinator, which is why two sequential executes look simultaneous on hardware. Planning is the bottleneck.

Key pointers

What	Where
Sync planning entry points	plan_to_pose, plan_to_joints in dimos/manipulation/manipulation_module.py
Blocking call	_plan_path_only in dimos/manipulation/manipulation_module.py
Per-arm result cache	dimos/manipulation/manipulation_module.py:128-130
Bimanual blueprint (mock, no HW)	openarm_mock_planner_coordinator in dimos/robot/manipulators/openarm/blueprints.py

Deliverables

• Concurrent plan_to_* across distinct robot_names — N plans complete in ~max(planning_time), not sum.
• preview_path and execute are non-blocking with respect to other arms.
• Bimanual demo on openarm_mock_planner_coordinator shows both arms plan + preview + execute overlapped, with timing logs.
• Single-arm behavior unchanged.

Notes

• Planner is CPU-bound — an async planner pool keyed by robot_name is one shape, but the design is open.
• WorldMonitor is shared across arms; concurrent plans need a snapshot or non-serializing read access.
• Cross-arm collision / coupled planning is out of scope.
• Validate on the mock bimanual first (no hardware needed).