[kenichi-maeda]

This PR includes:

• a new lbr_dual_arm_description demo package
• dual-arm mock and hardware bringup launches
• a dual-arm MoveIt config package
• a dual-arm MoveIt/RViz launch path
• prefixed joint/link naming for both arms (lbr_one_*, lbr_two_*)

Quick Demo:
Terminal 1:

ros2 launch lbr_dual_arm mock.launch.py

Terminal 2:

ros2 launch lbr_dual_arm move_group.launch.py \
      rviz:=true

Notes:

• Currently, the setup is fixed to two iiwa7 arms.
• This has not yet been validated with real robots.

@mhubii This is just an initial idea. I'd appreciate your feedback. Also, let me know if this change is not suitable for the upstream repo; in that case, I'll keep these chanegs local.

[mhubii]

sorry for the slow response @kenichi-maeda.

if you would benefit from these changes on humble, I am happy to merge. Given this PR targets humble, I hope it will correctly show up under contributions.

for jazzy, the current workflow backports PRs from rolling via cherrypicking through a github action. There, it may make more sense treating a dual setup as a downstream package, thus in a dedicated package, e.g. under demos.

[kenichi-maeda]

Thank you for the feedback. I have a few follow-up questions:

1. Should I rename this branch to follow the dev-<ros_version>-<feature> convention and reopen it?
2. My understanding is that the dual-arm setup should be refactored out of lbr_bringup and move into a dedicated downstream package under lbr_demos, so that the core bringup package stays clean. Is that correct?
3. For arm types, the current implementation is fixed to two iiwa7 arms. Would you prefer to keep that limited scope for now, or do you expect the dual-arm package to support configurable or mixed arm models?

[mhubii]

1. Should I rename this branch to follow the `dev-<ros_version>-<feature>` convention and reopen it?

Your branch name is better, and I will update the contributing guidelines.

2. My understanding is that the dual-arm setup should be refactored out of `lbr_bringup` and move into a dedicated downstream package under `lbr_demos`, so that the core bringup package stays clean. Is that correct?

From my understanding, this may make sense, but open to other perspectives. Any working solution would be great for now.

3. For arm types, the current implementation is fixed to two `iiwa7` arms. Would you prefer to keep that limited scope for now, or do you expect the dual-arm package to support configurable or mixed arm models?

That's totally fine.

[kenichi-maeda]

@garylvov looping you in here

[mhubii]

LGTM

[mhubii]

just FYI, this may not show up among contribution because it wasn't contributed to the main branch.

will try cherry pick these commits into rolling, hope this preserves contributions.