Pat, <div>The future stamping is a neat trick to get around network latency it's not good enough for "static transforms" without communication.  </div><div><br></div><div>The best way to look at it is through an example.  Think of sending things one minute in the future.  First, as tf only keeps 10 seconds of data per frame it will never be able to traverse that link for it won't have a common time between the future frame and the regular frames.  </div>

<div><br></div><div>Also, say you have a big enough buffer or you cut down the future stamping to 9 seconds.  It will take any node starting 9 seconds to be able to transform for it won't have information about the time it started up only about time in the future until the amount of time has passed by which you future stamped.  </div>

<div><br></div><div>I would suggest publishing at ~ 1Hz.  It's only a few lines of code to add it to any node and the computational and network overhead is very low. </div><div><br></div><div>Tully<br><br><div class="gmail_quote">

On Tue, May 25, 2010 at 10:35 AM, Patrick Bouffard <span dir="ltr"><<a href="mailto:bouffard@eecs.berkeley.edu">bouffard@eecs.berkeley.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

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.<br>


<br>Pat<div><div></div><div class="h5"><br><br><div class="gmail_quote">On Tue, May 25, 2010 at 10:29 AM, Josh Faust <span dir="ltr"><<a href="mailto:jfaust@willowgarage.com" target="_blank">jfaust@willowgarage.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
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.<br>




<br>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.<br>




<br>Why are you trying to future date transforms?<br><font color="#888888"><br>Josh<br><br></font><div class="gmail_quote"><div><div></div><div>On Mon, May 24, 2010 at 10:33 PM, Patrick Bouffard <span dir="ltr"><<a href="mailto:bouffard@eecs.berkeley.edu" target="_blank">bouffard@eecs.berkeley.edu</a>></span> wrote:<br>




</div></div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"><div><div></div><div>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:<br>





<br>No transform from [/grey/camera] to frame [/enu]<br><br>... however if I simply change the 600.1 to 600, there is no warning..<br><br>It looks like the constructor in rviz's frame_manager.cpp is where this happens:<br>





<br>FrameManager::FrameManager()<br>{<br>  tf_ = new tf::TransformListener(ros::NodeHandle(), ros::Duration(10 * 60), false);<br>}<br><br>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.<br>





<br>Thanks,<br>Pat<br>
<br></div></div><div>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
<br></div></blockquote></div><br>
<br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div><br>
</div></div><br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Tully Foote<br>Systems Engineer<br>Willow Garage, Inc.<br><a href="mailto:tfoote@willowgarage.com">tfoote@willowgarage.com</a><br>(650) 475-2827<br>
</div>