Ask Your Question

rosbag play & tf extrapolation problems

asked 2013-11-12 01:54:24 -0600

Tambo gravatar image

Hi everyone,

I wrote a program for collecting laser data from a bag (currently I'm using a bag from the gmapping node tutorial).

The bag is executed as usually: rosbag play bag

No problems so far, I can visualize everything in rviz. Problems are on the listener side. The callback, rather basic, is the following:

void callBack(const sensor_msgs::LaserScan::ConstPtr& msg)
     tf::TransformListener listener;
     tf::StampedTransform trans;
        ros::Time time=msg->header.stamp;
        listener.waitForTransform("base_laser", "odom", time, ros::Duration(1));
        listener.lookupTransform("base_laser", "odom", time, trans);
            //Do something
      catch(tf::TransformException ex)

In few words, it doesn't work, I always obtain:

Lookup would require extrapolation into the past


Lookup would require extrapolation into the future

I modified, by hand, the time variable value as follows:

ros::Time time=ros::Time(msg->header.stamp.sec+1);

Although it worked, to me is not a feasible or general solution.

Changing duration value didn't help either.

Am I doing something wrong? Maybe did I forget some parameter for ROS to set?

Thanks for your help,


edit retag flag offensive close merge delete

2 Answers

Sort by » oldest newest most voted

answered 2013-11-14 22:52:20 -0600

You should check for the return value of waitForTransform():

bool success = listener.waitForTransform("base_laser", "odom", time, ros::Duration(1));
if (success) {
    listener.lookupTransform("base_laser", "odom", time, trans);

What happens is that waitForTransform() fails, but you still call lookupTransform(), so that's where the exceptions come from.

The next step is figuring out why your lookups time out. It's normal if that happens for the first few laser scans, since your TF listener wasn't yet buffering TF messages before your node got started. But after a very short while, these errors should disappear.

One thing to check is that you set the queue size of your laser scan subscriber to a small value (like 1). Otherwise, you'll have the following problem:

  • The queue gets filled with laser scan messages from the "past" (i.e., the first second or so before the node was started).
  • Your callback works through the queue one message at a time; since waitForTransform() times out, this takes 1 second per message.
  • If you don't get a valid transform for the first 15 messages, all remaining messages will now fail because the TF buffer is only 15 seconds (or so) long.

This might also explain why adding 1 second "solves" the problem.

edit flag offensive delete link more

answered 2013-11-12 21:02:51 -0600

timster gravatar image

I think I have had a similar problem, my solution was to enable simulated time:

rosparam set use_sim_time true

Remember to set it for every ros session! And also remember to restart all your nodes after setting the parameter! The only thing now is to also publish the clock from the bag file:

rosbag play --clock your.bag

Does that help?

Best Tim

edit flag offensive delete link more

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: 2013-11-12 01:54:24 -0600

Seen: 1,766 times

Last updated: Nov 14 '13