Add latency checker heartbeat topics to domain bridge configurations

[Copilot]

This PR adds the necessary topic bridging configuration to enable the latency checker nodes to communicate across ROS 2 domains in the swarm system.

Problem

The latency checker nodes publish and subscribe to heartbeat topics to measure network latency between peers (host and drones). However, these topics were not configured in the domain bridge configurations, preventing cross-domain communication between:

• Host latency checker (running in domain 0)
• Drone latency checkers (each running in their respective domain numbers)

Solution

Added latency checker heartbeat topic bridging to both bridge configuration templates:

Host Bridge Config (host_bridge_config.yaml.j2)

• Host-to-drones: Bridges host heartbeat topic from domain 0 to all drone domains
• Drones-to-host: Creates separate bridge configurations for each drone's heartbeat topic from drone domain to host domain 0

Drone Bridge Config (drone_bridge_config.yaml.j2)

• Drone-to-host: Bridges the drone's own heartbeat topic from drone domain to host domain 0
• Host/peers-to-drone: Bridges host and other drones' heartbeat topics from domain 0 to the drone's domain

Topic Pattern

The latency checker uses the following topic naming convention:

• Topic: /{namespace}/latency_checker/heartbeat
• Message type: latency_checker_ros2/msg/Heartbeat

Where {namespace} is:

• Host: hostname with .local removed and - replaced with _
• Drones: nxt{N} where N is the drone number

Bridge Flow

1. Host publishes heartbeat → bridged to all drone domains
2. Each drone publishes heartbeat → bridged to domain 0 (host)
3. Cross-drone communication → routed via domain 0 hub

This enables full peer-to-peer latency monitoring between the host and all drones through the existing domain bridge infrastructure.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[nielmistry]

@copilot

[nielmistry]

Suggested change

	---
	# Bridge topics from host domain 0 to this drone domain
	name: host_to_drone_bridge
	from_domain: 0
	to_domain: {{ drone_num }}
	topics:
	# Host latency checker heartbeat to drone
	/{{ host_hostname | map('regex_replace', '\\.local', '') | map('regex_replace', '-', '_') | join('') }}/latency_checker/heartbeat:
	type: latency_checker_ros2/msg/Heartbeat
	# Other drones' latency checker heartbeats to this drone
	{% for peer in groups['drones'] %}
	{% set peer_num = peer | regex_replace('\\.local', '') | regex_search('[0-9]+$') %}
	{% if peer_num != drone_num %}
	/nxt{{ peer_num }}/latency_checker/heartbeat:
	type: latency_checker_ros2/msg/Heartbeat
	{% endif %}
	{% endfor %}

no need to have this here

[Copilot]

Removed the unnecessary second bridge configuration from drone bridge config. Now only bridges drone's own topics from drone domain to host domain 0. (b8aa47c)

[nielmistry]

you don't have to make a whole new for block. its the same as the above so just roll it in!

[Copilot]

Consolidated the latency checker topics into the existing for loop alongside the optitrack topics. Now both topics are bridged together for each drone domain. (b8aa47c)

[nielmistry]

unnecessary

[Copilot]

Removed the unnecessary additional bridge configurations. The latency checker topics are now handled within the existing single bridge configuration. (b8aa47c)