ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
2

waitForTransform use_sim_time python

asked 2011-06-02 07:39:42 -0500

phil0stine gravatar image

This is basically the same question as was asked here, but I am seeing the exact same behavior and haven't found a solution.

I am playing back a bag, using --clock, and setting use_sim_time correctly.

To summarize the problem, this works :

listener.waitForTransform('frame1','frame2',rospy.Time(),rospy.Duration(.1))
listener.lookupTransform('frame1','frame2',rospy.Time())

but this doesn't :

listener.waitForTransform('frame1','frame2',rospy.Time(),rospy.Duration(.1))
time_stamp=listener.getLatestCommonTime('frame1','frame2') # This does return the sim time
listener.lookupTransform('frame1','frame2',time_stamp)

nor does this :

listener.waitForTransform('frame1','frame2',time_stamp,rospy.Duration(100.0)) 
listener.lookupTransform('frame1','frame2',time_stamp)

The error returned is :

You requested a transform that is 278350010.097 miliseconds in the past, but the most recent transform in the tf buffer is 278350024.236 miliseconds old.

The most recent transform seems to always be a very small time ahead of the requested transform.

Do I need to migrate this node to C++, or am I doing something wrong?

Thanks in advace

-Phil Osteen, Motile Robotics Inc.

edit retag flag offensive close merge delete

4 Answers

Sort by ยป oldest newest most voted
4

answered 2011-06-17 12:59:18 -0500

Wim gravatar image

Simulated time is broken in certain cases with rospy and tf. This problem got fixed in tf2, which is part of the geometry_experimental stack. But as the stack name suggests, this is still experimental code. Tf2 might make it into Electric.

edit flag offensive delete link more
1

answered 2011-06-17 11:32:14 -0500

kwc gravatar image

simulated time does not work in certain cases with rospy and tf, unfortunately, and will require a fairly heavy redesign to fix.

edit flag offensive delete link more
1

answered 2011-06-02 08:49:00 -0500

updated 2011-06-02 08:55:24 -0500

Shot in the dark:

You might try adjusting the Hz on your rosbag --clock

rosbag might be doing bad time approximations. By increasing or decreasing the clock publish speed, you might be able to get it to line up correctly. I'd be kind of surprised if this works but perhaps worth a try.

edit flag offensive delete link more

Comments

Didn't work, but it's something I definitely wouldn't have thought of. I can run tf_echo and verify that the transforms are being broadcast at the right time, but I get the exception for the same two frames, with the same timestamp.
phil0stine gravatar image phil0stine  ( 2011-06-03 02:06:23 -0500 )edit
This might be for a different topic, but I am interested in your theory about rosbag doing bad time approximations. Have you ran into this before, or are there any other posts on the subject? Thanks
phil0stine gravatar image phil0stine  ( 2011-06-03 02:27:03 -0500 )edit
I might not be correct, but I seem to remember coming across some documentation or forum post claiming that rosbag's timing can be a bit rough. If I find where I saw that I'll link to it here.
Asomerville gravatar image Asomerville  ( 2011-06-03 03:20:33 -0500 )edit
1

answered 2011-06-03 04:55:48 -0500

phil0stine gravatar image

Here was the issue.

For my implementation, NodeA receives a message from the past, then analyzes the data and broadcasts to /tf, with the timestamp of the original message.

I also have NodeB publishing a different transform to /tf at a much higher rate.

I want to compare the two broadcasts, so another node waits until something from NodeA is broadcast to /tf.

listener.waitForTransform('frame1','frame2',rospy.Time(),rospy.Duration(.1))
listener.lookupTransform('frame1','frame2',rospy.Time())
time_stamp=listener.getLatestCommonTime('frame1','frame2') # This does return the sim time

Then checks the /tf from NodeB at that time

listener.waitForTransform('frame3','frame4',time_stamp,rospy.Duration(100.0)) 
listener.lookupTransform('frame3','frame4',time_stamp)

I expected that, even if the transform time from NodeA was earlier than the first transform from NodeB, waitForTransform would find the nearest transform after that, which is why I ramped up the timeout to 100.

Since NodeB runs at a high rate, I wouldn't care if waitForTransform retuned the next transform that it published. But an exception is thrown regardless.

I tried to start the bag at different times, to make sure one node didn't take longer to start, but the same problem would exist at arbitrary points in the bag.

Not the most satisfying explanation (hopefully not too confusing), but the end result is that I can move on.

Thanks for the help, and I would still be very interested if anybody could provide a link regarding rosbag time approximation

edit flag offensive delete link more

Question Tools

1 follower

Stats

Asked: 2011-06-02 07:39:42 -0500

Seen: 3,890 times

Last updated: Jun 17 '11