[ros-users] Future-dating tf transforms by more than 10 minutes?

[Patrick Bouffard]

I have one transform that is determined at run-time, during startup, and
never changes. It's only used for visualization, and I'd rather not trouble
the node that determines it with having to rebroadcast it periodically, a la
static_transform_publisher, nor have to communicate it to another node to do
that job.

Pat

On Tue, May 25, 2010 at 10:29 AM, Josh Faust <jfaust at willowgarage.com>wrote:

> 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 at 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 at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100525/74cfdd3f/attachment-0003.html>