ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Is there any way that I can - with just one topic - provide a new client the latest N messages?

No, this is not supported (but with a trick you may be able to get close, see below).

Latching is a very limited implementation of the "late joiner gets history" concept (essentially a history depth/length of 1). There is no way to configure the depth in ROS 1.

It is however a depth of 1 per publisher IIRC. So if creating multiple publishers would be ok, you could create a publisher per message, make them all latched and late joiners would get all of them. That's not very nice though.

Or do I have to create a dedicated service to provide the latest N messages, which the client then will have to carefully synchronize with the ongoing publishing of log messages?

you seem to present somewhat of a false dilemma here: it isn't either-or I'd say. It's unfortunate ROS 1's latching isn't configure (as ROS 2's is, with DDS QoS as a back-end), but there are probably various other alternative approaches that could be used. Your idea with a service being one of them.

Is there any way that I can - with just one topic - provide a new client the latest N messages?

No, this is not supported (but with a trick you may be able to get close, see below).

Latching is a very limited implementation of the "late joiner gets history" concept (essentially a history depth/length of 1). There is no way to configure the depth in ROS 1.

It is however a depth of 1 per publisher IIRC. So if creating multiple publishers would be ok, you could create a publisher per message, make them all latched and late joiners would get all of them. them (note: it could be that multiple publishers in the same node to the same topic share the queue, which would make this not work again). That's not very nice though.

Or do I have to create a dedicated service to provide the latest N messages, which the client then will have to carefully synchronize with the ongoing publishing of log messages?

you seem to present somewhat of a false dilemma here: it isn't either-or I'd say. It's unfortunate ROS 1's latching isn't configure (as ROS 2's is, with DDS QoS as a back-end), but there are probably various other alternative approaches that could be used. Your idea with a service being one of them.