Mantain sequence ID equal to the one of input message
Hi everyone,
I'm currently using Cartographer and I'm looking for an easy way to keep the sequence ID from resetting. I'll explain myself better: since I'm running Cartographer ROS in a container, I'll be moving that container around, which means that the node will be deleted and re-created multiple times. The problem is that the sequence ID in the header of cartographer's messages will be resetting each time, which is a problem for my infrastructure. One solution would be to set the sequence ID = sequence ID of the input message, but I don't have enough expertise to change Cartographer's code (I don't even know where to start). Is there an easy way to do this using ROS' settings? Or in general to keep the sID from resetting?
Thank you in advance!
Not an answer, just a quick comment.
If you're referring to
header.seq, that's been deprecated for almost as long as I can remember. There is also no guarantee anyone sets it, nor is the behaviour betweenroscppandrospythe same (not to mention any 3rd party client libraries).Depending on it, or using it for anything doesn't sound like a good idea.
Well ok, looks like I'll have to find another way then... Thank you for your time :)
What are you trying to do for which you wanted to use
seq?Sync messages from two different topics, but I'll just put them in separate lists and use a more custom solution
Have you seen message_filters? Specifically the policy based synchronizers?
Yes, but since I could have varying delays it's a solution that doesn't really work. However, since the two nodes that I sync will output the same number of messages, I can just put the messages of the faster node in a queue and send everything we the messages from the slower one arrive.
isn't that what the time-based synchronisers are supposed to solve? The 'window' in which two messages are considered to 'belong together' is configurable.
Additionally: synching is done based on
header.stamp, not reception time. Those are two very different things.One case where they really don't work easily is when there is a large difference in message rates. But you write:
so it sounds like that's not the case.
If you could describe what you really want to do in a bit more detail, perhaps we could see whether there is a solution available somewhere.