[Feature Request] ros2topic get_msg_class() should return msg class for remapped topics

[Interpause]

Feature request

Feature description

Currently, ros2topic's get_msg_class() returns None when getting the msg class of a remapped topic. This is inconvenient for generic subscribers (i.e. msg synchronizers) that do not know the msg class ahead of time. For example:

• Publisher node publishes msg class String to /publisher_out.
• Subscriber node uses get_msg_class(self, "/subscriber_in", blocking=True) to wait for publisher on /subscriber_in.
• ros2launch remaps /subcriber_in to /publisher_out.
• Subscriber node stalls indefinitely as get_msg_class(self, "/subscriber_in", blocking=True) never returns.
• However, using get_msg_class(self, "/publisher_out", blocking=True) in Subscriber node works.

Implementation considerations

https://github.com/ros2/ros2cli/blob/fc02ffe4c9b242da9b50e4c9c8a8c94fdd58f0c7/ros2topic/ros2topic/api/__init__.py#L97-L98

https://github.com/ros2/ros2cli/blob/fc02ffe4c9b242da9b50e4c9c8a8c94fdd58f0c7/ros2topic/ros2topic/api/__init__.py#L114-L141

_get_msg_class() could check if topic is remapped and which topic it was remapped to, using that topic instead to get the msg class. However, I cannot seem to find any is_topic_remapped() or get_topic_map() function in rclpy, is this a limitation?

My workaround so far has been to avoid remapping altogether and use parameters to specify which topic to subscribe/publish to. However, it does not make sense that remapping has to be thrown away altogether just to perform generic subscription.

[fujitatomoya]

@Interpause thanks for posting issue.

This is inconvenient for generic subscribers (i.e. msg synchronizers) that do not know the msg class ahead of time.

I might be missing something, this seems to be related to topic name, not message type? could you elaborate about msg synchronizers a bit if possible?

ros2launch remaps /subcriber_in to /publisher_out.

can you provide complete command line for this? or launch file? I am not sure what you want to do here.

However, I cannot seem to find any is_topic_remapped() or get_topic_map()

i think there is no such interfaces. remapping is taken place in rcl, not in rmw. So middleware is agnostic from remapping.

[Interpause]

@Interpause thanks for posting issue.

This is inconvenient for generic subscribers (i.e. msg synchronizers) that do not know the msg class ahead of time.

I might be missing something, this seems to be related to topic name, not message type? could you elaborate about msg synchronizers a bit if possible?

ros2launch remaps /subcriber_in to /publisher_out.

can you provide complete command line for this? or launch file? I am not sure what you want to do here.

However, I cannot seem to find any is_topic_remapped() or get_topic_map()

i think there is no such interfaces. remapping is taken place in rcl, not in rmw. So middleware is agnostic from remapping.

Sorry for the late reply. After reading a bit more, I think the way remapping occurs might mean its actually impossible for the node to introspect about it. Fixing it probably would require significant changes to ROS2's architecture...

Given it is impossible to fix, maybe it could be mentioned in the ROS2 documentation tutorials about the alternative method of using parameters to set topic names instead of remapping, and perhaps bring up the fact remapping has the limitation of not being able to detect the topic type.