Queue builds up and introduces timing issues

[NikolasE]

We had a timing issue where we found a growing delay in the pose-messages that we receive through the bridge. In a ROS2-callback, we compared the reception time of the pose-message with the header.stamp and found a growing delay which made it impossible to use the data for navigation.

We have the suspicion that this was caused by the way how the data from the locator itself was queued:

The parsing function (that parses a single telegram) is called in the onReadEvent of the TCP-connection. If the parse-function (that also includes the publishers) can't keep up, new telegrams are only added to the queue, but there is no way to remove them again. As soon as we have more than one message in the queue, each time we get a new message, it will be added to end of the queue and we will parse the oldest one, but the queue length stays the same.

https://github.com/boschglobal/locator_ros_bridge/blob/6701960499b0baa0ae6bc6187c9d54c54554c068/bosch_locator_bridge/src/receiving_interface.cpp#L47

Do I interpret this behavior correctly?

[kfabian]

Thanks for pointing this out! I could verify the described behavior by adding some artificial delay to the message parsing. The buffer fills up, but since tryToParseData is only called once per read event the buffer will never empty. I implemented a quick fix in #23.

[slaible]

We tested the fixed version and the problem with the growing delay seems to be solved. It is now also implemented in the noetic branch. @NikolasE Could you please give us feedback, we would then close this issue.

[NikolasE]

We are using the 1.4.3 version of the locator with galactic, so we are on an older version. We are currently using our own fork with a similar fix (we just delete the whole queue after reading one message) and our delay problems are gone.

[slaible]

Ok, great to hear that!