Robotics StackExchange | Archived questions

When would a ApproximateTime Sync stop calling ist callback?

Hi there!

I have two topics that I want to synchronize. One is running at a rate of 20 Hz, the other one approx. at 28 Hz. I am using the following code.

In the header file I define:

   typedef message_filters::sync_policies::ApproximateTime<sensor_msgs::PointCloud2, sensor_msgs::PointCloud2>   SyncPolicy;

message_filters::Subscriber<sensor_msgs::PointCloud2> cloud_sub1;
message_filters::Subscriber<sensor_msgs::PointCloud2> cloud_sub2;
message_filters::Synchronizer<SyncPolicy> *sync_;

In the cpp file:

  cloud_sub1.subscribe(nh, "in/points1", 30);
  cloud_sub2.subscribe(nh, "in/points2", 30);

  sync_ = new message_filters::Synchronizer<SyncPolicy>(SyncPolicy(30), cloud_sub1, cloud_sub2);
  sync_->registerCallback(boost::bind(&Hello::callback, this, _1, _2));

The code works, but after many hours of running my project it can happen, that the callback is not called anymore, even though the node is still alive.

  1. Does the queue size passed here cloud_sub1.subscribe(nh, "in/points1", 30); have any effect? I can set this to -1 and it still seems to be generally working.
  2. I must admit I do not really understand the ApproximateTime algorithm described here But from my understanding, it should always call its callback, when there are actually messages in both queues (which I have verified - both incoming topics still send data, even in times the callback is not called anymore). When is the callback not called? What does that tell us about the messages in the queues?
  3. Is the queue size passed to the SyncPolicy set to all subscribers? I thought it would be a queue for already matched "sets", but why can I set the queue size of the subscribers to -1 then?

Hope someone can help :)

Asked by Jay4Ros on 2022-04-07 09:14:44 UTC

Comments

FYI, your link in #2 is not valid.

Asked by Mike Scheutzow on 2022-04-08 07:41:26 UTC

thanks, I fixed the link.

Asked by Jay4Ros on 2022-04-11 01:47:37 UTC

Answers

The most likely reason the filter would stop producing output is if there is some issue with the header timestamps of the input. If the timestamp values of the two streams are far apart, I wouldn't expect this filter to produce output.

Asked by Mike Scheutzow on 2022-04-08 07:40:23 UTC

Comments

sounds logical, even though the "Max interval duration" is disabled by default and unfortunately I don't see a way to inspect the queues. You don't have any insight into the different parameters for the queue sizes?

edit: but the sentence "it does assume that messages arrive in order on each topic, but not even necessarily across topics (though the queue size must be large enough if there are big differences or messages will be dropped)." strongly supports your suspicion, I guess :)

Asked by Jay4Ros on 2022-04-11 01:52:20 UTC

There are multiple ways you can dig deeper: 1) After the problem happens, use rostopic echo to examine the input topic msgs, or 2) Modify the filter source code to log a warning if the input timestamp difference is greater than some threshhold.

Asked by Mike Scheutzow on 2022-04-11 06:43:54 UTC