ROS 2 multi-drone visibility across different ROS_DOMAIN_IDs and access to inter-drone topics

[mehdi-belal]

I want to start a discussion about how inter-drone topic visibility is handled

At the moment, each aircraft runs with its own ROS_DOMAIN_ID:

Drone 1 -> domain 1
Drone 2 -> domain 2
Drone 3 -> domain 3
Drone 4 -> domain 4

This isolates each drone ROS graph, which is useful for avoiding collisions and keeping each vehicle stack separated. However, it also means that drones cannot directly discover each other’s ROS 2 topics through DDS. some topics such as /state_sharing_drone_N are still visible inside the aircraft containers because they are being forwarded through zenoh-bridge-ros2dds nodes.

The thing that I find complicated is the management of information when there is an external node that must for example send information to all the others sitting in specific ROS_DOMAIN_IDs, this can still be done with the same mechanism as the topic seen before but it becomes a bit heavy architectural-wise.

I’d like to hear if there's something intended here.

[JacopoPan]

Hi @mehdi-belal, your analysis is correct and indeed the intent is to:

• isolate ROS domains (this is a bit safer and sometimes makes it even easier to integrate ROS packages that are namespaced following different conventions);
• force the developer of multi-drone behaviours to be a bit more conscious and deliberate in selecting the information to share over a wireless link (which is a typical pain point in deployments).

It is true that this is overkill for single host, multi-agent simulation but it makes the code more "aligned" (🥃) with deployment and it should not be too complicated, as the topic broadcasting across ROS domains is handled by just a couple of .json5 files:

aerial-autonomy-stack/ground/ground_resources/comms/zenoh_config_ground.json5

Lines 1 to 10 in 89ff6d9

	{
	plugins: {
	ros2dds: {
	allow: {
	publishers: ["/tracks"],
	subscribers: []
	}
	}
	}
	}

aerial-autonomy-stack/ground/ground.yml.erb

Line 57 in 89ff6d9

- zenoh-bridge-ros2dds -c /aas/ground_resources/comms/zenoh_config_ground.json5

aerial-autonomy-stack/aircraft/aircraft_resources/comms/zenoh_config_air.json5.erb

Lines 1 to 17 in 89ff6d9

	<% drone_id = ENV.fetch('DRONE_ID', 1).to_i %>
	{
	plugins: {
	ros2dds: {
	allow: {
	publishers: ["/state_sharing_drone_<%= drone_id %>"],
	subscribers: ["/tracks", "/state_sharing_drone_.*"]
	}
	}
	},
	scouting: {
	multicast: {
	enabled: true
	}
	}
	}

aerial-autonomy-stack/aircraft/aircraft.yml.erb

Lines 86 to 87 in 89ff6d9

	erb /aas/aircraft_resources/comms/zenoh_config_air.json5.erb > /aas/aircraft_resources/comms/zenoh_config_air.json5 &&
	zenoh-bridge-ros2dds -e tcp/<%= gnd_container ? "#{air_subnet}.90.#{ground_id}" : "#{sim_subnet}.90.#{sim_id}" %>:7447 -c /aas/aircraft_resources/comms/zenoh_config_air.json5

Of course, I'm more than open to suggestions on how to make this even simpler.