Evaluate rmw_zenoh as a DDS discovery alternative

[adharshvenkat]

Problem

DDS discovery (Fast DDS, the Jazzy default) is unreliable in this Docker Compose setup: nodes intermittently fail to appear in ros2 node list until the ROS2 daemon is manually restarted (ros2 daemon stop && ros2 daemon start). This is a known class of issue with multicast-based DDS discovery across Docker's bridge networking and stale daemon caches, not specific to any one node.

Impact

• Intermittent, hard-to-reproduce failures where running nodes are invisible to ros2 CLI tools and to each other, requiring a manual daemon restart to recover.
• Adds friction and uncertainty when validating the stack, and would be a bad look if it surfaced during a live demo.

Proposed approach

Evaluate rmw_zenoh_cpp as an alternative RMW implementation. It replaces DDS's multicast discovery with a router-based, unicast-friendly model, and requires no application code changes since ROS2's RMW layer is a drop-in abstraction. Concretely:

• Install ros-jazzy-rmw-zenoh-cpp in the Dockerfile runtime stage.
• Add a zenoh-router service to docker-compose.yml, reachable by all ROS-bearing containers.
• Set RMW_IMPLEMENTATION=rmw_zenoh_cpp for all ROS services.
• Re-run the full command -> plan -> navigate -> succeed loop and confirm no regressions, paying particular attention to larger/high-rate payloads (depth images, costmaps) which fragment differently under zenoh than DDS.

This should be scoped as an isolated spike: the change is contained to Dockerfile/compose config with no application code changes, and is trivially reversible (revert one env var) if it doesn't pan out.

Acceptance criteria

• Full end-to-end demo loop (NL command -> plan -> nav -> succeed) validated on rmw_zenoh_cpp.
• Node/topic discovery is confirmed reliable across multiple fresh container starts, without needing a daemon restart.
• No regression in depth image / costmap / semantic map topic delivery.
• Decision recorded: adopt as new default, or revert and keep DDS, with the reasoning either way.