roscpp: Multiple latched publishers per process on the same topic (fix #146)

[meyerj]

At the moment roscpp (and probably most other client libraries) does not support multiple latched publishers on the same topic within a single process, because the latched message is stored in the Publication singleton instead of in individual publishers (#146) and each publication of another publisher invalidates the previous latched message. This situation is unfortunate because in many cases it is hard to control which components in a single process do publish latched topics and how they are deployed, e.g. for Gazebo or move_base plugins.

My colleague @achim-k and I have been working on a patch for roscpp that enables multiple latched subscribers in a single process, following my proposal in #146 (comment). The solution is similar to what @mgrrx has done for Python.

While this patch does solve the issue for online publishing and our current needs, I do not see a good general solution for rosbag yet. It would be possible to instantiate one patched Publisher per connection during the replay, such that latched topics from different original publishers would mimic the recorded situation correctly during the replay. rosbag already creates one internal publisher per topic and callerid. So with this patch in roscpp latched publications of different nodes will be replayed correctly (see also #1537). But without modifications to the ROS protocol there is no way to tell which internal publisher instance of a node published which message if there is more than one, which would be required to replay messages as seen during the recording and to know which message invalidates which message seen earlier on the same topic.

For the special case of replaying tf_static it might be an option to collect static transforms while iterating over the bag file and each time publish a new TFMessage message that contains all found transformations so far.

Unfortunately the patch is not ABI compatible and also changes the behavior significantly, so it can not be merged in melodic-devel or even backported to kinetic.

[ablakey]

This is interesting. Are there common cases for wanting multiple latched publishers?

From my perspective, this frustrates the idea that topics are streams of state and a single message is a moment of state. I'm assuming your desire is for new subscribers to receive (in or out of order?) a series of messages from n latched publishers on a single topic.

You mention multiple publishers in the same process. Have you considered using a wrapper message that allows you to publish an array of that message type to a topic instead?

Consider that treating a collection of messages as a single moment of state frustrates rosbag (as you've alluded to) and other common tools/processes.

[flixr]

We also use multiple "latched" publishers on the same topic (in our case mostly /diagnostics) for things that we don't want to republish at fixed intervals as longs as they don't change.
The workaround we use is to use a normal publisher, but monitor the subscribers and just republish every time a new subscriber is added.

[meyerj]

From #1544 (comment):

This is interesting. Are there common cases for wanting multiple latched publishers?

The most prominent use-case is tf_static. It is conceptually broken in my opinion if it is not possible to latch more than one message per process. Using a shared tf2_ros::StaticTransformBroadcaster is not an option either because in many cases publishers do not know about each other (nodelets, plugins, ...).

From my perspective, this frustrates the idea that topics are streams of state and a single message is a moment of state. I'm assuming your desire is for new subscribers to receive (in or out of order?) a series of messages from n latched publishers on a single topic.

Exactly. It should not make a difference whether there are multiple latched publishers in separate processes or in a single process. Each publisher delivers its last message.

You mention multiple publishers in the same process. Have you considered using a wrapper message that allows you to publish an array of that message type to a topic instead?

Not an option for the tf_static use-case where the message type cannot be changed. Or did I misunderstand you?

Consider that treating a collection of messages as a single moment of state frustrates rosbag (as you've alluded to) and other common tools/processes.

... depending on the queue size of subscribers. If the queue size is greater or equal the number of publishers, there is no problem with receiving more than one latched message from the same node. tf2_ros::TransformListener creates subscribers on /tf and /tf_static with a queue size of 100. Same for rosbag record.

From #1544 (comment):

The workaround we use is to use a normal publisher, but monitor the subscribers and just republish every time a new subscriber is added.

Yes, that would be a viable workaround to "emulate" latched publishing, in cases where you can control the creation of the publisher and inject custom subscriber callbacks. Nevertheless, the approach proposed here is more general and I cannot think of a use-case where it is actually desirable that one publisher "overwrites" the message published by another publisher instance.

It might be an option to apply this method to tf2_ros::StaticTransformPublisher, which could probably be done without breaking ABI. In combination with a patch to rosbag for special handling of tf_static as proposed above, at least this use case could be solved properly (for roscpp and rospy).

[meyerj]

Jenkins build errors seem to be unrelated?

[cwecht]

@ros-pull-request-builder retest this please

[peci1]

Bump?

[meyerj]

Any chance that this patch gets included for the upcoming ROS Noetic or any future ROS 1 release, alongside a similar patch by @mgrrx for rospy? Or is it considered too much of behavioral change without a proper design review process?

In combination with #1537 the resulting behavior of recording and replaying latched topics (e.g. /tf_static) is almost correct, in the sense that the situation seen by other subscribers during replay is close to the situation at the time the bag file was recorded. Only in cases where the original publisher node had multiple latched publishers, the data recorded in bag files cannot distinguish them anymore because the callerid is the same for all of them (see PR description).

[dirk-thomas]

Any chance that this patch gets included for ... any future ROS 1 release

Atm Noetic is the last ROS 1 distribution Open Robotics plans to release. So its either Noetic or potentially never since the patch is ABI / behavior breaking (which makes it a no-go for an already released distro).

Any chance that this patch gets included for the upcoming ROS Noetic.

I am slightly concerned that the explicit check for mismatching publisher option could lead to existing code to break.

That being said I understand why this enhancement would be very valuable to have. If necessary we can hopefully address issues in an ABI compatible way in a patch version after the initial release.

So 👍 from me to merge for Noetic. Thanks for working on this.

alongside a similar patch by @mgrrx for rospy?

It doesn't seem there is a PR for the Python side but I don't consider that a blocker for this,