[ros-users] Confusion with TF...

[Jason Owens]

On Wed, Apr 14, 2010 at 2:18 PM, John Hsu <johnhsu at willowgarage.com> wrote:
> Hi,
> It's hard to debug this issue without being able to reproduce the problem...

I figured that might be the case...

> 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

I'll work on creating a mini-pkg; until then, I've uploaded two bag
files at http://public.me.com/robocoder (the jitter has the matching
tf rate 10Hz, and the no_jitter has 13Hz), and I've attached the
frames and wtf output to this message. I do notice that for some
reason, the frame.pdf shows the messages as being quite old - is this
something that has to do with gazebo? When I look at the
ros::Time::toSec() when the system is running, I get values that match
the ROS time displayed in rviz, i.e. starting from 0.

Thanks for looking at this!
-Jason

>
> 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 at 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 at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: frames.pdf
Type: application/pdf
Size: 11730 bytes
Desc: not available
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100414/ccbfc5eb/attachment-0005.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wtf.out
Type: application/octet-stream
Size: 1784 bytes
Desc: not available
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100414/ccbfc5eb/attachment-0005.obj>