tf doesn't have an idea of static transforms, so rebroadcasting is the only
solution atm.

Josh

On Tue, May 25, 2010 at 10:35 AM, Patrick Bouffard <
bouffard@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.
>
> Pat
>
>
> On Tue, May 25, 2010 at 10:29 AM, Josh Faust <jfaust@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@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
>>>
>>>
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users@code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>