[ros-users] Confusion with TF...

[Jason Owens]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pseudocreate.launch
Type: application/octet-stream
Size: 2304 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/ros-users/attachments/20100414/0acdbd59/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pseudocreate.xml
Type: text/xml
Size: 8432 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/ros-users/attachments/20100414/0acdbd59/attachment-0002.xml>