Latching more than one message
I have a latched topic that publishes a kind of log messages. When a client connect, he will get the latest log message, however this is often too limited, since the client needs to know what has happened in the past as well as what is happening right now. Ideally I would want to be able to define the number of messages to be latched.
Is there any way that I can - with just one topic - provide a new client the latest N messages?
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?
Asked by knxa on 2019-10-28 09:07:23 UTC
Answers
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 (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.
Asked by gvdhoorn on 2019-10-28 09:39:52 UTC
Comments
I did hope for a trick I had not yet discovered and you provided one. However I think that using multiple publishers is too odd and not very scalable.
Asked by knxa on 2019-10-29 15:19:39 UTC
Well as I wrote: latching is really only meant for receiving the last message. It was never meant to support receiving the last-n-messages. It could be added, but considerations such as memory usage could come up (I can see people trying to use this with pointclouds).
Asked by gvdhoorn on 2019-10-29 22:15:23 UTC
You cloud publish a vector of you topic and implement a deque. Insert on the back, pop out on the front. And republish it
Asked by duck-development on 2019-10-28 13:25:06 UTC
Comments
Interesting idea. But if the desired number of historic items is large then this quickly becomes a traffic heavy solution.
Asked by knxa on 2019-10-29 15:14:48 UTC
You right, but if you like to get something for speed, acceleration, jerk compution. Out of one message you can do it so.
Asked by duck-development on 2019-10-31 02:35:58 UTC
Comments