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

TF2 - static_transform_publisher - Extrapolation into the future

asked 2014-09-19 07:45:25 -0500

Rabe gravatar image

Hello,

I have a couple of static_transform_publishers from the TF2 package running. How is it possible that a node complains about extrapolating into the future, when it tries to lookup a transformation from a random element to the static one? In my understanding, the static-transforms should be valid for all eternity, so why would you complain about timing issues?

A further explanation about my setup:

I have 2 Kinects and I am using those in my moveIt setup to create the Octomap. As explained here, moveIt complains about extrapolation into the future while looking up a transform from my robot to the cameras.

My first solution was to write a python node, which would handle all the publishing instead of seperate static_transform_publishers from the old TF. There, I could date the transformations back in time to avoid those issues.

Now I read about the static transforms in TF2 and implemented all the camera transformations like this:

<node pkg="tf2_ros" type="static_transform_publisher" name="camera_top_base_link_1" args="0 -0.045 0 0 0 0 1 /camera_top/camera_top_link camera_top/camera_top_rgb_frame  " />

Still, moveIt is complaining

[ERROR] [1411130239.665581579]: Transform error: Lookup would require extrapolation into the future.  Requested time 1411130239.663295803 but the latest data is at time 1411130239.541714906, when looking up transform from frame [finger_2_link_0] to frame [camera_top/camera_top_depth_optical_frame]
[ERROR] [1411130239.997648183]: Transform cache was not updated. Self-filtering may fail

But running `rosrun tf tf_echo /finger_2_link_0 camera_top/camera_top_depth_optical_frame has no problems and tells me the transforms moveIt couldn't find?

Thanks in advance,

Rabe

edit retag flag offensive close merge delete

Comments

Have you tried reducing static_transform_publisher's publishing frequency from the current rate (1000Hz)? I would suggest that you decrease that frequency to 10Hz or even 1Hz.

Mani gravatar image Mani  ( 2014-09-19 08:22:12 -0500 )edit

Why is there a rate at all? My understandin was that it was "static" as in "published once"? Anyway, I can't even set the rate in the current way it is implemented, see the file here

Rabe gravatar image Rabe  ( 2014-09-19 09:28:31 -0500 )edit

I also tried various rates with the old implementation of tf, which didn't change anything either

Rabe gravatar image Rabe  ( 2014-09-19 09:29:16 -0500 )edit

@Rabe Sorry, I made a mistake when reading your static_transform_publisher command.

Mani gravatar image Mani  ( 2014-09-19 13:41:59 -0500 )edit

2 Answers

Sort by ยป oldest newest most voted
3

answered 2014-09-19 11:00:58 -0500

ahendrix gravatar image

I suspect static transform isn't the problem here.

The problem here is that MoveIt is requesting a very recent transform, and your system hasn't published that transform yet. Note that the time differential here is pretty small, about 0.12 seconds, so it's most likely just a processing delay somewhere in your system.

I would start by running rosrun tf tf_monitor to inspect the transform delays in your system, and then follow up by looking through the tf Troubleshooting guide

edit flag offensive delete link more
1

answered 2014-09-19 10:43:19 -0500

Tom Moore gravatar image

As I understand it, tf2's static_transform_publisher does indeed publish a single static transform, instead of tf's method of sending it continuously. However, users can still work with tf, even though it uses tf2 under the hood. To that end, I don't really know how MoveIt! works internally, but if it's using tf and not tf2, then my guess is that somewhere within the inner workings of tf/tf2, the transform is getting sent out repeatedly in the style of tf. Try using the original tf static_transform_publisher, which lets you set a broadcast rate in ms, and see if that fixes the problem.

edit flag offensive delete link more

Question Tools

1 follower

Stats

Asked: 2014-09-19 07:45:25 -0500

Seen: 4,538 times

Last updated: Sep 19 '14