Hi,
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

rosrun tf view_frames
roswtf

You can see most of the tf debugging tools at:

http://www.ros.org/wiki/tf/Debugging%20tools

Lastly, there's a tf troubleshoot page here that might be helpful:

http://www.ros.org/wiki/tf/Troubleshooting

thanks,
John

On Wed, Apr 14, 2010 at 6:30 AM, Jason Owens <jlowens@gmail.com> wrote:

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