Hi,<br>It's hard to debug this issue without being able to reproduce the problem... is there a way you can create a pseudo-package which we can run and reproduce the symptoms?  Also, can you also attach outputs from<br>

<br>rosrun tf view_frames<br>roswtf<br><br>You can see most of the tf debugging tools at:<br><br><a href="http://www.ros.org/wiki/tf/Debugging%20tools">http://www.ros.org/wiki/tf/Debugging%20tools</a><br><br>Lastly, there's a tf troubleshoot page here that might be helpful:<br>

<br><a href="http://www.ros.org/wiki/tf/Troubleshooting">http://www.ros.org/wiki/tf/Troubleshooting</a><br><br>thanks,<br>John<br><br><div class="gmail_quote">On Wed, Apr 14, 2010 at 6:30 AM, Jason Owens <span dir="ltr"><<a href="mailto:jlowens@gmail.com">jlowens@gmail.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;">Hello all,<br>
<br>
I've been having some issues with tf, time and gazebo... quite<br>
possibly due to a case of newbie-itis. Perhaps the simplest question<br>
is this:<br>
<br>
Why would changing the update rate of the gazebo_ros_p3d plugin from<br>
10Hz -> 11Hz make the laser scans bounce all over the place when<br>
moving the robot?<br>
<br>
I am confused as to why increasing the data rate of the pose transform<br>
would cause the laser scans (both sensor frame and transformed world<br>
frame point cloud) to jitter so much. I feel like this is an issue,<br>
since when I implement SLAM on board a real robot, I will not be able<br>
to have great control over the data publish rate, which other nodes<br>
may depend on (e.g. an incremental generalized voronoi graph builder).<br>
<br>
A little more background:<br>
<br>
Given a create-like simulated robot with differential drive,<br>
hokuyo-like laser, the gazebo-ros-p3d plugin publishing ground-truth<br>
pose, another node publishing the /world -> /base_link transform based<br>
on this pose info, and a node that builds an occupancy grid -<br>
everything works quite well (i.e. rviz shows the map and laser data<br>
"cleanly"). This is when the updateRate of the p3d plugin is set to<br>
some multiple of 10Hz (which is the rate of the laser). However, if I<br>
perturb the updateRate of the ground truth (i.e. 13Hz, 15Hz, 19Hz),<br>
the laser scans start to jump around quite a bit in rviz, and the<br>
occupancy grid gets very messy. I realize a real robot will not have a<br>
perfectly clean map, but I am trying to understand the problem with<br>
the transforms here so I can mitigate it.<br>
<br>
I *am* using tf::MessageFilter, and have tried a variety of queue<br>
sizes and tolerances, but to no avail. I actually first noticed the<br>
problem when running on a laptop with 2 instead of 4 cores (like my<br>
desktop), and it was clear not all the messages were being received.<br>
roswtf doesn't show anything of interest (other than the /time topics<br>
are unconnected, which I assume is due to "/use_sim_time = true"?). I<br>
thought it was due to extrapolation, but it seems extrapolation is<br>
disabled by default. However, if I print the extrapolation_mode from<br>
the time_cache I get *a lot* of extrapolate_forward cases... which I<br>
thought the tf::MessageFilter would prevent.<br>
<br>
I have attached a copy of my urdf and launch file, if they may help.<br>
<br>
Thanks ahead for any suggestions! Also - thank you so much for ROS; so<br>
far, it has made my life easier in many ways, and hopefully I'll be<br>
able to convince my employer (DoD) to allow us to contribute our<br>
source back to the community.<br>
<font color="#888888"><br>
-Jason<br>
</font><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>