[ros-users] Issues with rviz

Tully Foote tfoote at willowgarage.com
Tue May 25 22:37:59 UTC 2010


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 <jfaust at willowgarage.com> 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 <
> j.elseberg at jacobs-university.de> 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
>> > <j.elseberg at jacobs-university.de
>> > <mailto:j.elseberg at jacobs-university.de>> 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
>> >     > <j.elseberg at jacobs-university.de
>> >     <mailto:j.elseberg at jacobs-university.de>> 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
>> >     >>> <j.elseberg at jacobs-university.de
>> >     <mailto:j.elseberg at jacobs-university.de>
>> >     <mailto:j.elseberg at jacobs-university.de
>> >     <mailto:j.elseberg at jacobs-university.de>>>
>> >     >>> 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 <http://ros.org/wiki/tf>
>> >     >>>    <http://ros.org/wiki/tf>
>> >     >>>    >>> <http://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"
>> >     >>>    <j.elseberg at jacobs-university.de
>> >     <mailto:j.elseberg at jacobs-university.de>
>> >     >>>    <mailto:j.elseberg at jacobs-university.de
>> >     <mailto:j.elseberg at jacobs-university.de>>
>> >     >>>    >>>> <mailto:j.elseberg at jacobs-university.de
>> >     <mailto:j.elseberg at jacobs-university.de>
>> >     >>>    <mailto:j.elseberg at jacobs-university.de
>> >     <mailto:j.elseberg at jacobs-university.de>>>> 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
>> >     >>>    >>>> <Fixed_Frame> 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 at code.ros.org <mailto:ros-users at code.ros.org>
>> >     <mailto:ros-users at code.ros.org <mailto:ros-users at code.ros.org>>
>> >     >>>    <mailto:ros-users at code.ros.org
>> >     <mailto:ros-users at code.ros.org> <mailto:ros-users at code.ros.org
>> >     <mailto:ros-users at code.ros.org>>>
>> >     >>>    >>>> https://code.ros.org/mailman/listinfo/ros-users
>> >     >>>    >>>>
>> >     >>>    >> _______________________________________________
>> >     >>>    >> ros-users mailing list
>> >     >>>    >> ros-users at code.ros.org <mailto:ros-users at code.ros.org>
>> >     <mailto:ros-users at code.ros.org <mailto:ros-users at code.ros.org>>
>> >     >>>    >> https://code.ros.org/mailman/listinfo/ros-users
>> >     >>>    >>
>> >     >>>    >>
>> >     >>>    >>
>> >     >>>    >
>> >     >>>    >
>> >     >>>    >
>> >     >>>    >
>> >     >>>
>> >     >>>    _______________________________________________
>> >     >>>    ros-users mailing list
>> >     >>>    ros-users at code.ros.org <mailto:ros-users at code.ros.org>
>> >     <mailto:ros-users at code.ros.org <mailto:ros-users at code.ros.org>>
>> >     >>>    https://code.ros.org/mailman/listinfo/ros-users
>> >     >>>
>> >     >>>
>> >     >>>
>> >     >>>
>> >     >>> --
>> >     >>> Tully Foote
>> >     >>> Systems Engineer
>> >     >>> Willow Garage, Inc.
>> >     >>> tfoote at willowgarage.com <mailto:tfoote at willowgarage.com>
>> >     <mailto:tfoote at willowgarage.com <mailto:tfoote at willowgarage.com>>
>> >     >>> (650) 475-2827
>> >     >>>
>> >     >> _______________________________________________
>> >     >> ros-users mailing list
>> >     >> ros-users at code.ros.org <mailto:ros-users at code.ros.org>
>> >     >> https://code.ros.org/mailman/listinfo/ros-users
>> >     >>
>> >     >>
>> >     >>
>> >     >
>> >     >
>> >     >
>> >     >
>> >
>> >     _______________________________________________
>> >     ros-users mailing list
>> >     ros-users at code.ros.org <mailto: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
>>
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>


-- 
Tully Foote
Systems Engineer
Willow Garage, Inc.
tfoote at willowgarage.com
(650) 475-2827
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100525/cee17506/attachment-0003.html>


More information about the ros-users mailing list