If transforms are also being broadcast at the current time, it's going to be
limited by whatever the cache time is on the TransformListener being used.
rviz uses 10 minutes (which is probably a bit high), but anything using the
default time will be limited to 10 seconds.

10 minutes was chosen as "arbitrarily high", so that rviz would always work
over spotty wireless.  It should probably be lowered to a minute or so.  The
downside to a large cache time is that it can negatively affect performance.

Why are you trying to future date transforms?

Josh

On Mon, May 24, 2010 at 10:33 PM, Patrick Bouffard <
bouffard@eecs.berkeley.edu> wrote:

> Is there a limitation on how far in the future the timestamp of a transform
> broadcast by a tf::TransformBroadcaster can be? If there was I would have
> expected it to be perhaps the default tf cache time of 10.0 seconds, but my
> experimentation (this is with boxturtle) seems to indicate it is 600
> seconds. In particular, I'm looking at the frame in rviz, and if I set the
> timestamp to ros::Time::now() + ros::Duration(600.1), then I get the
> following warning in rviz, and the frame does not have the right data:
>
> No transform from [/grey/camera] to frame [/enu]
>
> ... however if I simply change the 600.1 to 600, there is no warning..
>
> It looks like the constructor in rviz's frame_manager.cpp is where this
> happens:
>
> FrameManager::FrameManager()
> {
>   tf_ = new tf::TransformListener(ros::NodeHandle(), ros::Duration(10 *
> 60), false);
> }
>
> It looks like this is unchanged in trunk as well. Is there is some reason
> why ten minutes was chosen? Are there drawbacks to making this longer? Or
> configurable? Ten minutes is fine for my present application but it seems to
> be somewhat arbitrary.
>
> Thanks,
> Pat
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>