Hi Jason Can you pose the nodes that are publishing the necessary tf transforms as well? thanks, John On Wed, Apr 14, 2010 at 2:37 PM, Jason Owens wrote: > 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 > > > > > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > >