Hi, The issue was indeed due to the time_increment. It was set using milliseconds instead of seconds. Thanks alot for the help. Jan Tully Foote wrote: > Jan, > Based on your topic name it looks like you are using a Sick LMS. > There is a ROS driver for it in the sicktoolbox_wrapper which you > might find useful to either use or for a reference. It is documented > at http://www.ros.org/wiki/sicktoolbox_wrapper > > Tully > > On Tue, May 25, 2010 at 3:31 PM, Josh Faust > wrote: > > Hi Jan, > > It looks like the time_increment field in your laser scans are set > to 0.0924214... this field is meant to be the amount of time > between each reading in the scan, so 90 milliseconds is quite > high. rviz multiplies this by the number of readings in the scan > to set the time tolerance on the filter it uses, to ensure that > the entire message can be transformed correctly, not just the > first reading. > > A more reasonable time_increment would be a few orders of > magnitude smaller. An example from our tilting laser is > 1.73611115315e-05 > > I've filed a ticket to make rviz warn in cases of unreasonably > large time_increment values: > https://code.ros.org/trac/ros-pkg/ticket/4123 > > Josh > > > On Tue, May 25, 2010 at 1:45 AM, Jan Elseberg > > wrote: > > Hi, > > I uploaded a short bag.file of the robot. You can get it under > http://plum.eecs.jacobs-university.de/exchange/volksbot.bag . > There's also > http://plum.eecs.jacobs-university.de/exchange/only_laser.bag > where only > the laser topic (/volksbotRT/LMS) and /tf is recorded. If you need > anything else, please let me know. > > Jan. > > Josh Faust wrote: > > Can you post a bag file with /tf and the laser scan topic > somewhere? > > > > Josh > > > > On Fri, May 21, 2010 at 5:21 AM, Jan Elseberg > > > > >> wrote: > > > > Wim, > > > > I have played around with the timestamps of the laser > scan message. > > Neither increasing nor decreasing > > the timestamp changes the behaviour, except that for > large enough > > offsets either of the following errors > > is produced: > > > > For frame [/front_laser]: No transform to fixed frame > > [/base_link]. TF > > error: [You requested a transform that > > is 2.637 miliseconds in the past, but the most recent > transform in the > > tf buffer is 8.092 miliseconds old.] > > > > For frame [/front_laser]: No transform to fixed frame > > [/base_link]. TF > > error: [You requested a transform that > > is 3.212 seconds in the past, but the tf buffer only has > a history of > > 3.138 seconds.] > > > > I have also changed the publishing frequency of the > laser scan > > messages > > to 5 Hz. Unfortunately, this also had > > no effect on the error. > > > > Jan > > > > > > Wim Meeussen wrote: > > > Jan, > > > > > > When rviz receives laser scan messages, it only keeps > the 10 most > > > recent messages in a buffer. So, if you send > laserscans at 50 Hz (it > > > looks like that's the rate you use), that means rviz > only stores 0.2 > > > seconds worth of laser scans. So when your laser scans > are more than > > > 0.2 seconds ahead of your tf transforms, rviz would be > unable to > > > transform any laser scans. To find out if this is the > problem > > you hare > > > seeing, you should modify the timestamps of your laser > scan > > messages, > > > by deducting something like 1 second from each > timestamp before > > > sending out the message from the laser scanner driver. > Or you could > > > create a node that takes in laser scanner messages, > modifies the > > > timestamp, and send out the modified laser scans. > > > > > > Wim > > > > > > > > > On Thu, May 20, 2010 at 9:33 AM, Jan Elseberg > > > > > >> wrote: > > > > > >> Hi, > > >> > > >> the issue occurs when using rviz on a seperate computer > > (synchronized to the > > >> robot with ntp) as well as when used only on the > robot. The > > tf-tree of rviz > > >> is attached, it is the same as before. > > >> > > >> Jan > > >> > > >> Tully Foote wrote: > > >> > > >>> Jan, Are you running rviz on a seperate machine? If > so make > > sure that the > > >>> clocks are synced using ntp or similar between the > multiple > > machines. > > >>> To see the tf tree that rviz is using try running > "view_frames > > >>> --node=rviz_******" where ******* is the UUID of the > anonymous > > rviz process > > >>> which you can get from rosnode list. > > >>> Tully > > >>> > > >>> On Thu, May 20, 2010 at 9:19 AM, Jan Elseberg > > >>> > > > > > > > >>> > > >>> wrote: > > >>> > > >>> Wim, > > >>> > > >>> the timestamps of the laser scans are concurrent > to the > > ones I'm > > >>> getting > > >>> with "rostopic echo /tf". > > >>> I was under the impression that tf would give me > an error > > of some kind > > >>> in this scenario ? > > >>> Also, if the issue lies with my tf-tree, > shouldn't there be > > similar > > >>> problems in my node > > >>> that transforms the laser scans into the /map > frame using the > > >>> tf::TransformListener ? > > >>> > > >>> Regards, > > >>> > > >>> Jan > > >>> > > >>> > > >>> > > >>> Wim Meeussen wrote: > > >>> > Jan, > > >>> > > > >>> > Your tf tree looks fine, but it is possible > that the > > timestamps of > > >>> > your laser scans are wrong. Your tf buffer keeps a > > 10-seconds window > > >>> > of transformations. When the timestamp of your > laser scan > > does > > >>> not fit > > >>> > in that 10 seconds window, tf won't be able to > transform it. > > >>> From the > > >>> > data you sent, it looks like your tf buffer is > nicely > > synchronized > > >>> > with the current time in your system, so I > would suspect > > that your > > >>> > laser scans have timestamps that are either > more than 10 > > seconds in > > >>> > the past, or some number of seconds in the future. > > >>> > > > >>> > You can check the timestamp of your laser scans > using > > "rostopic echo > > >>> > laser_scan/header/stamp". > > >>> > > > >>> > Wim > > >>> > > > >>> > > > >>> > > > >>> > > > >>> >> I've attached the results of view_frames. I > have also > > tried the > > >>> other stuff > > >>> >> on the troubleshooting guide. Transformations > between > > the laser > > >>> frame and > > >>> >> every other frame work fine. Across the > longest tf-chain > > >>> (/front_laser to > > >>> >> /map) the average delay is approx 25ms and the > maximal > > delay is > > >>> approx. > > >>> >> 55ms. From this it appears to me that the > tf-tree is > > correctly > > >>> set up, but > > >>> >> maybe there is something else I can check? > > >>> >> > > >>> >> Regards, > > >>> >> > > >>> >> Jan Elseberg > > >>> >> Eitan Marder-Eppstein wrote: > > >>> >> > > >>> >>> Jan, > > >>> >>> > > >>> >>> It sounds like something may be wrong with > your transform > > >>> tree. Can you > > >>> >>> try running "rosrun tf view_frames"? This > will generate > > a PDF > > >>> of the current > > >>> >>> transform tree structure. You may also want > to check the > > >>> troubleshooting > > >>> >>> link on the sidebar of this page: http://www > > .ros.org/wiki/tf > > > >>> > > >>> >>> for more information > on useful tf > > >>> debugging > > >>> >>> strategies. > > >>> >>> > > >>> >>> Hope this helps, > > >>> >>> > > >>> >>> Eitan > > >>> >>> > > >>> >>> > > >>> >>>> On May 20, 2010 3:38 AM, "Jan Elseberg" > > >>> > > > > > >>> > > >> > > >>> >>>> > > > > > >>> > > >>>> wrote: > > >>> >>>> > > >>> >>>> Hi everyone, > > >>> >>>> > > >>> >>>> I am trying to get our robot to work with > the navigation > > >>> stack of ros. > > >>> >>>> I've been following the tutorial on > > >>> >>>> > http://www.ros.org/wiki/navigation/Tutorials/RobotSetup . > > >>> After setting > > >>> >>>> up the robot with a tf-tree and sensor nodes > , I have > > noticed > > >>> a problem > > >>> >>>> with rviz. I am unable to display the laserscan > > messages in > > >>> any frame > > >>> >>>> other than the laser coordinate system > itself, i.e., > > whenever > > >>> I select a > > >>> >>>> other than /front_laser the > status of > > the laser > > >>> scan > > >>> >>>> display shows the error: > > >>> >>>> > > >>> >>>> "Unknown reason for transform failure". > > >>> >>>> > > >>> >>>> Also, this warning appears in the bash: > > >>> >>>> > > >>> >>>> [WARN] 1274341043.701801000: MessageFilter > > [target=/base_link > > >>> ]: Dropped > > >>> >>>> 99.03% of messages so far. Please turn the > > >>> [ros.rviz.message_notifier] > > >>> >>>> rosconsole logger to DEBUG for more information. > > >>> >>>> > > >>> >>>> Doing so gives me these repeating debug > messages: > > >>> >>>> > > >>> >>>> MessageFilter [target=/base_link ]: Added > message in frame > > >>> /front_laser > > >>> >>>> at time 1274341252.994, count now 10 > > >>> >>>> MessageFilter [target=/base_link ]: Removed > oldest message > > >>> because > > >>> >>>> buffer is full, count now 10 > (frame_id=/front_laser, > > >>> >>>> stamp=1274341252.813649). > > >>> >>>> > > >>> >>>> This suggests a problem with the tf-tree to me. > > However, when > > >>> using the > > >>> >>>> "transformPoint(...)" function of > > tf::TransformListener in my > > >>> own nodes > > >>> >>>> to transform the laser scan into the global > frame > > everything > > >>> works as > > >>> >>>> intended with no errors/warnings. > > >>> >>>> > > >>> >>>> Does someone have an idea what I am doing wrong? > > >>> >>>> > > >>> >>>> Thank you for any help! > > >>> >>>> > > >>> >>>> > > >>> >>>> Jan Elseberg > > >>> >>>> > > >>> >>>> _______________________________________________ > > >>> >>>> 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 > > >>> > > >>> > > >>> > > >>> > > >>> -- > > >>> Tully Foote > > >>> Systems Engineer > > >>> Willow Garage, Inc. > > >>> tfoote@willowgarage.com > > > > > > >> > > >>> (650) 475-2827 > > >>> > > >> _______________________________________________ > > >> 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 > > > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > > > > > -- > Tully Foote > Systems Engineer > Willow Garage, Inc. > tfoote@willowgarage.com > (650) 475-2827