ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A
Ask Your Question

When would a ApproximateTime Sync stop calling ist callback?

asked 2022-04-07 09:14:44 -0500

Jay4Ros gravatar image

updated 2022-04-11 01:47:07 -0500

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 :)

edit retag flag offensive close merge delete


FYI, your link in #2 is not valid.

Mike Scheutzow gravatar image Mike Scheutzow  ( 2022-04-08 07:41:26 -0500 )edit

thanks, I fixed the link.

Jay4Ros gravatar image Jay4Ros  ( 2022-04-11 01:47:37 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2022-04-08 07:40:23 -0500

Mike Scheutzow gravatar image

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.

edit flag offensive delete link more


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 :)

Jay4Ros gravatar image Jay4Ros  ( 2022-04-11 01:52:20 -0500 )edit

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.

Mike Scheutzow gravatar image Mike Scheutzow  ( 2022-04-11 06:43:54 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2022-04-07 09:14:44 -0500

Seen: 48 times

Last updated: Apr 11