Replies: 4 comments 10 replies
-
|
Hi Antoine, I guess not, but maybe you can elaborate what the term latching topic refers to, so we can tell you whether there is a replacement! :) Best Regards |
Beta Was this translation helpful? Give feedback.
-
|
Arf, too bad. Any chance this could be a feature request ? Is it aligned with current design decisions ? That being said, having a callback called whenever a new subscriber appears could do the trick. I need to see it in action to understand if this is actually practical. |
Beta Was this translation helpful? Give feedback.
-
|
I don't want to say no to ever implementing something like that, but at the moment I honestly don't see enough need for this feature to implement it myself. Did I understand you correctly, that this is a publisher feature? So if you have 10 publishers, each having the |
Beta Was this translation helpful? Give feedback.
-
|
Yes. It should of course be an option, in some cases you don't want to have the topic latching. |
Beta Was this translation helpful? Give feedback.
-
|
This feature that you're asking for would bring alot of additional logic with it on the eCAL side. I don't know if it would be possible to have "Latching" Publishers, that communicate only on a certain eCAL Transport Layer, e.g. TCP, where there is actually an underlying 1:1 connection. |
Beta Was this translation helpful? Give feedback.
-
|
Definitely not expecting to see it on the UDP layer. An option only available on the TCP layer is perfectly fine. |
Beta Was this translation helpful? Give feedback.
-
|
This sample is demonstrating the Events API for a publisher. |
Beta Was this translation helpful? Give feedback.
-
|
@FlorianReimold any updates on this ? |
Beta Was this translation helpful? Give feedback.
-
|
Sorry to disappoint you, but latching topics are not on our TODO list, at the moment. As I understand it, to have such a feature, eCAL would have to:
While the TCP layer should in theory be able to satisfy those requirements, any other layer is not and it would require a lot of effort to implement such a feature in eCAL. What you currently can do is use the Event API in your publisher and then simply re-sending the latest data. (See the post by rex-shilasky above for an example). Honestly I think such a user-space workaround should be fine and would be rather easy to implement. Have you tried it? |
Beta Was this translation helpful? Give feedback.
-
|
When communicating via shared memory, may be able to use the shared memory as the buffer without additional buffering logic. I modified the following two files(just for test) and possible to subscribe data like latched
but, for the publisher option posted by @ahoarau in #774 (reply in thread)_ need to modify more ... |
Beta Was this translation helpful? Give feedback.
-
|
The next few days we'll discuss eCAL roadmap for the upcoming year, and to be honest, I am not a big fan of the feature (even though the implementation you suggested is quite elegant, because it requires little changes), because in case of other transport layers it will require more effort. So we would have to understand more clearly the requirements of this, especially the "why". So why should we implement it. Also, should this be reflected in the user callback then? does the user need to know if the first data that is being received is old or not? So - potentially a lot of questions 😄 |
Beta Was this translation helpful? Give feedback.
-
The question was initially posted as I was searching for a cross-platform alternative to ROS. At the time ecal had TCP support, necessary for not losing messages, but was indeed lacking latching topics. Use case is pretty simple: initialisation of nodes. A new node might arrive "late" in the system and needs for example the robot_state message to be initialized, or some parameters. For robot_state, is it usually streamed, so you won't have to wait very long to get a message, but for event-based topics, it's a way of getting the latest message without having the server to issue an "empty update" for everybody. I understand this can be worked-around without too much effort. Latching topics simply offers a bit for more control over the dataflow. For your extra questions, my guess would be to copy the ROS behavior (= server decides, and it's completely transparent for client). That being said, having the info that the message is latched or not is very interesting 👍 |
Beta Was this translation helpful? Give feedback.
-
Hello,
Does ecal has the same "latching" topic mecanism implemented, as in ROS ?
I can't find the answer in the docs or code.
Thanks !
Beta Was this translation helpful? Give feedback.
All reactions