ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
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.
2 | No.2 Revision |
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.