[ros-users] Future-dating tf transforms by more than 10 minutes?
jfaust at willowgarage.com
Tue May 25 18:30:44 UTC 2010
tf doesn't have an idea of static transforms, so rebroadcasting is the only
On Tue, May 25, 2010 at 10:35 AM, Patrick Bouffard <
bouffard at eecs.berkeley.edu> wrote:
> 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.
> 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
>> Why are you trying to future date transforms?
>> 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
>>> 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.
>>> ros-users mailing list
>>> ros-users at code.ros.org
>> ros-users mailing list
>> ros-users at code.ros.org
> ros-users mailing list
> ros-users at code.ros.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ros-users