On Wed, Apr 14, 2010 at 2:18 PM, John Hsu 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 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 >> > > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > >