[KrishnaH96]

Branch krishna/feat/dual-openyam-leader-on-module, base krishna/feat/leader-teleop-module @ 7969c63 (PR #5177, DIM-129 PR3), merged in, not rebased. Supersedes krishna/feat/dual-openyam-leader-teleop-v3 (DIM-617), whose module code PR1 replaced.

Why

The dual OpenYAM leader teleop on v3 carried its own Feetech reader, calibration, CLI and module. PR1 made those generic: the robot is a mapping table. This PR is the dual OpenYAM table and its two blueprints, nothing else.

What

In dimos/robot/manipulators/dual_openyam/blueprints/:

• leader_teleop.py: MAPPINGS, one SideMapping per side, joints arm/<side>_joint1..6 from the planning model, limits from dual_openyam.urdf, scale 1 and offset 0 (flips live in the calibration file), GripperMapping(joint_7, 1.5 rad). Velocity limits 3 rad/s on the arm, 4 rad/s on the wrists. Blueprint dual-openyam-leader-teleop = LeaderTeleopModule (6 Hz command filter, 10 ms tick, both measured on the OpenArm) + LeaderCoordinator (own worker process since PR1 7969c63) + DualOpenYamConnection + ManipulationModule for Viser, wired by port name. --simulation swaps in the mock reader parked at the home pose and the mock connection.
• leader_collection.py: learning-collect-leader-dual-openyam = the teleop blueprint + collect(profile=...) + EpisodeMonitorModule + three D405 color streams (overhead, left wrist, right wrist). Profile: observation.state is coordinator_joint_state and action is arm_position_command, the coordinator's command stream to the connection (it publishes no coordinator_joint_command for connection robots); both 14 arm/-named joints as the Quest collection names them; three observation.images.* at 480x640.
• Tests for both, registry entries, gateway annotations, a docs page.

Ports, CAN names and camera serials come from flags or the run config. No classes in blueprints, nothing under dimos/control, dimos/teleop/leader or the connection.

On PR1 @ 7969c63

leader_task() is the coordinator's canonical joint_trajectory task (priority 10) bound to leader_joint_command; it is used unmodified and is the only trajectory task, so the planner shares the lane. leader_gripper_tasks(DualOpenYamConnection.robot.grippers) gives left_arm_gripper and right_arm_gripper with the jaws' open_at, the same names ManipulationModule gets under the dual OpenYAM planning groups left_manipulator and right_manipulator. The YAM trigger sits at servo ID 7, so the calibration records it as joint_7 and the mapping names that motor; the gripper name applies to leaders with a trigger at ID 8.

Not in this PR

• The operator/follower split blueprints from v3 (two machines over a zenoh router).
• v3's anchored two-point trajectories over execute_trajectory. PR1 streams the leader's JointState into the trajectory task as 1-point guarded jogs, one per 10 ms tick; smoothing beyond the 6 Hz filter belongs to cc's trajectory-task fix.
• Hardware validation at this head (below; runbook in HW_RUNBOOK_PR3.md).
• The recorder's strict quality mode rejects an episode on one dropped camera frame; the docs page says to set quality.mode to fill in the recording's schema.json before prepare. Raised with cc, not worked around here.

How to test

uv sync --extra manipulation --extra leader-teleop --inexact
uv run pytest dimos/robot/manipulators/dual_openyam dimos/teleop/leader dimos/codebase_checks
dimos --simulation run dual-openyam-leader-teleop

On Anvil: FDEIssues/openyam-leader/HW_RUNBOOK_PR3.md, one step at a time (branch check, calibration copy, joint-tui per side, real leaders on the mock follower, hardware follow, one recording, inspect and prepare).

Checks

Head 5c15156 (merge of PR1 @ 7969c63, then one commit).

• pytest dimos/robot/manipulators/dual_openyam dimos/teleop/leader with the self_hosted marker included: 104 passed (URDF limit test and simulation composition test on the local model asset)
• pytest dimos/codebase_checks dimos/cli/hardware dimos/robot/test_all_blueprints_generation.py: 195 passed, 3 skipped (optional SDKs)
• pytest experimental/gateway/tests -k "annot or catalog or config": 46 passed
• ruff, ruff format --check, mypy on the four changed files, deptry dimos --config pyproject.toml: clean; no non-ASCII
• dimos --simulation run dual-openyam-leader-teleop --leaderteleopmodule.reader mock, 60 s: LeaderCoordinator module_id=1 worker_id=0 alone on its worker, TickLoop started at 100.0Hz, 5884 Executing trajectory on joint_trajectory: 1 points lines (about 100 per second), no errors, one expected warning (the pool auto-scaling for the dedicated modules)
• Hardware at this head:

Stacked on #5177 (PR1); sibling of #5182 (PR2, OpenArm Mini). Hardware check on the OpenYAM rig pending; runbook in the branch owner's notes.

[github-actions]

go2 replay realtime (arm64)

Details

Benchmark suite	Current: 5c15156	Previous: 83800d9	Ratio
peak memory	1766.285 MB	1745.215 MB	1.01
peak threads	367 threads	368 threads	1.00
network (transport)	2736.226 MB	2730.954 MB	1.00
disk write	1.895 MB	1.863 MB	1.02
instructions	138.83 G	138.7 G	1.00

This comment was automatically generated by workflow using github-action-benchmark.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

@@                          Coverage Diff                          @@
##           krishna/feat/leader-teleop-module    #5184      +/-   ##
=====================================================================
+ Coverage                              83.77%   83.79%   +0.01%     
=====================================================================
  Files                                   1884     1888       +4     
  Lines                                 183104   183317     +213     
  Branches                               15077    15086       +9     
=====================================================================
+ Hits                                  153400   153611     +211     
- Misses                                 25687    25689       +2     
  Partials                                4017     4017              

Components	Coverage Δ
Tests	96.68% <100.00%> (+<0.01%)	⬆️

Flag	Coverage Δ
OS-macos-latest	78.05% <90.14%> (+0.01%)	⬆️
OS-ubuntu-24.04-arm	77.81% <90.14%> (+0.01%)	⬆️
OS-ubuntu-latest	78.18% <90.14%> (+0.01%)	⬆️
Py-3.10	78.17% <90.14%> (+0.01%)	⬆️
Py-3.11	78.15% <90.14%> (+0.01%)	⬆️
Py-3.12	78.17% <90.14%> (+0.01%)	⬆️
SelfHosted-Linux	40.74% <56.33%> (+0.02%)	⬆️
SelfHosted-macOS	40.48% <56.33%> (+0.03%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
dimos/robot/all_blueprints.py	100.00% <ø> (ø)
...ators/dual_openyam/blueprints/leader_collection.py	100.00% <100.00%> (ø)
...ipulators/dual_openyam/blueprints/leader_teleop.py	100.00% <100.00%> (ø)
.../dual_openyam/blueprints/test_leader_collection.py	100.00% <100.00%> (ø)
...tors/dual_openyam/blueprints/test_leader_teleop.py	100.00% <100.00%> (ø)

... and 6 files with indirect coverage changes

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.