laser scans not showing when fixed frame is not equal to the laser scans frame id #332

wjwwood · 2018-06-28T23:46:41Z

I see this on Ubuntu 18.04 with the bouncy deb binaries.

Steps to reproduce:

ros2 launch dummy_robot_bringup dummy_robot_bringup.launch.py
rviz2
Add a display by topic and use /scan
Add the tf display
Add a map display for /map
Set the fixed frame to world

You'll see the map and the tf frames moving, but no laser scan. If you look at the laser display you'll see that the status is Ok, but the Points field just says Showing [0] points from [0] messages and it is not rendered. I would expect it to be rendered.

If you change the fixed frame to single_rrbot_hokuyo_link you can see the laser scans and the status adds the Transform: Ok status. However, the map no longer renders and prints to the console [ERROR] [rviz2]: Error transforming map 'Map' from frame 'world' to 'single_rrbot_hokuyo_link'. and it also sets a similar message, Could not transform from [world] to [single_rrbot_hokuyo_link] in the status part of the map display.

My expectation is that both the laser and map should work in either (or any) fixed frame.

The text was updated successfully, but these errors were encountered:

Martin-Idel-SI · 2018-06-29T07:27:16Z

The main problem seems to be a missing transform. Could you publish a static transform from [world] to e.g. [single_rrbot_hokuyo_link] (or any tf frame of the robot)? I'll have to update my ros2 installation again before I can reproduce.

The TF display should also show this, are there any warnings with fixed frame [world] or [single_rrbot_hokuyo_link]?

The current behaviour is that we only show displays if there is a transform available between the fixed frame and the frame of the part to show (i.e. lookupTransform(...) returns true). It seems that the transform between [world] and [single_rrbot_hokuyo_link] is not available in tf2, so we can't really know how to position the map.

The same is probably true for the laser scan display. The behaviour that I want is that it also shows the same status error (and prints to the console). This should have been done in #292 but the laser scan display wasn't touched, so I missed it.
That part at least is a bug in rviz and I'll prepare a PR to fix it.

wjwwood · 2018-06-29T07:47:58Z

There are correct transforms from world to the laser frame, but they’re not all static transforms. This use case should work and it did work in the past, I used this demo before to show the laser scans moving at the end of the tf tree which waving back and forth.

wjwwood · 2018-06-29T07:49:05Z

But I don’t know what the root cause is. I’ll look into when I get time if you guys can’t reproduce it.

Martin-Idel-SI · 2018-06-29T07:52:40Z

That should be okay, yes.

I've seen the dummy robot in the past, too, but I can't run the launch file currently (probably have to update my installation). We'll definitely look into it on Monday.

But when the map frame prints out "error transforming" then we must hit this line:

rviz/rviz_default_plugins/src/rviz_default_plugins/displays/map/map_display.cpp

Line 544 in 6b0d290

    
           RVIZ_COMMON_LOG_ERROR_STREAM("Error transforming map '" << getName().toStdString() <<

which implies that some transforms failed.

Martin-Idel-SI · 2018-07-02T07:52:07Z

I updated my ros installation and can now reproduce.

In the debugger, the error thrown that leads the map (or LaserScanDisplay) to not show anything is here:

https://github.com/ros2/geometry2/blob/e9861210b1e5c905fea7da5c21b6990bdfe64648/tf2/src/buffer_core.cpp#L678

I get several different errors (not sure when I get which errors). When map is not showing, I get
Could not find a connection between 'world' and 'single_rrbot_hokuyo_link' because they are not part of the same tree.Tf has two or more unconnected trees.

So to me, this seems to be either a bug in TF or the robot doesn't publish its transforms correctly.

I also sometimes get a flickering laser scan (including a map) with the errors:
Lookup would require extrapolation into the future. Requested time 1530519582,77282 but the latest data is at time 1530519580,63707, when looking up transform from frame [world] to frame [single_rrbot_hokuyo_link]

If I remember correctly, this is a problem in laser_scan_display: A laser scan needs to have transforms available for quite some time and previously, message filters made sure that this happened before letting the message through. Since message_filters aren't ported, yet, there is not much we can do.

In RViz, here is what we should do:

We should definitely show the user there is a problem also in the LaserScanDisplay
We might also want to log the exact error message to the console or even to the status message, but I'm not sure whether it helps to have the exact TF error message in the RViz status.
We could also always show the TF error in the status message, but that's a bit more work, because we need to adjust the interface of frame_manager.

Martin-Idel-SI · 2018-07-03T08:22:29Z

After a few more tries and working a bit more with logging, I can get a consistent picture:

The problem is indeed the error message

Lookup would require extrapolation into the future. Requested time 1530519582,77282 but the latest data is at time 1530519580,63707, when looking up transform from frame [world] to frame [single_rrbot_hokuyo_link]

So it's a mismatch of transformation data.

From my understanding, this was previously handled by message filters, which would allow a certain tolerance to deal with transforms (see https://answers.ros.org/question/217429/use-cases-for-tfmessagefiltersettolerance/). Since message filters aren't available yet the tolerance feature had to be disabled (see the TODO here:

rviz/rviz_default_plugins/src/rviz_default_plugins/displays/laser_scan/laser_scan_display.cpp

Line 62 in 6b0d290

    
           // TODO(Martin-Idel-SI): Reenable once tf_filter is ported or delete if necessary

), I don't have any good solution for this issue right now.

What I don't understand though is that the map is also not displayed (extrapolation into the future) if my fixed frame is the single_rrobot_link3 or the camera or laser scan frame. I would have expected tf to allow a transform between world and dynamic frame /single_rrobot_link3, but calling lookupTransform throws an extrapolation exception, too (and therefore, you see the error `[rviz2]: Error transforming map 'Map' from frame 'world' to 'single_rrobot_link3'.

The three bullet points in my previous message still apply.

robotpilot · 2018-08-17T01:26:39Z

FYI, I can't see the laser data on rviz2 even if the fixed frame is the same as the frame_id of node of laser scanner.

wjwwood · 2018-08-17T01:29:36Z

@robotpilot we need more info for that to be useful information (it might be a different issue). Which version of ROS 2/rviz are you using and are there any messages on the console that indicate a problem?

robotpilot · 2018-08-17T02:04:32Z

[Case 1]

Ubuntu 16.04
ROS2 Bouncy Bolson (build from source code)
Used packages: dummy_robot_bringup and rviz2

$ ros2 launch dummy_robot_bringup dummy_robot_bringup.launch.py

$ rviz2

I am also in the same state as you. The laser scans not showing when fixed frame is not equal to the frame_id of laser scans. In addition, setting the fixed frame to world, single_rrbot_link1, and single_rrbot_link2 did not show the laser value. So I set it to single_rrbot_link3, single_rrbot_camera_link, single_rrbot_hokuyo_link, and I could see the laser value at rviz2.

[Case 2]

Ubuntu 16.04
ROS2 Bouncy Bolson (build from source code)
Used packages: hls_lfcd_lds_driver for ROS2 and rviz2

$ ros2 run hls_lfcd_lds_driver hlds_laser_publisher

$ ros2 topic echo /scan

header:
  stamp:
    sec: 1534470809
    nanosec: 149773231
  frame_id: laser
angle_min: 0.0
angle_max: 6.2657318115234375
angle_increment: 0.01745329238474369
time_increment: 2.9930000891909003e-05
scan_time: 0.0
range_min: 0.11999999731779099
range_max: 3.5
ranges: [0.6909999847412109, 0.6710000038146973, 0.671999990940094, 0.6399999856948853, 0.5899999737739563, 0.5590000152587891, 0.5389999747276306, 0.531000018119812, 0.5230000019073486, ....

$ rviz2

I can't see the laser data on rviz2 even if the fixed frame is the same as the frame_id of topic of /scan.

The status of rviz2 is Ok and it says xxxxx message received, but the Points field just says Showing [0] points from [0] messages.

robotpilot · 2018-08-17T05:03:50Z

[case 3]

FYI, I have only run dummy_laser in the dummy_sensors package, but I could not see the laser value on rviz. (setting: Fixed Frame single_rrbot_hokuyo_link)

$ ros2 run dummy_sensors dummy_laser

$ ros2 topic echo /scan

header:
  stamp:
    sec: 1534481872
    nanosec: 924202607
  frame_id: single_rrbot_hokuyo_link
angle_min: -2.356194496154785
angle_max: 2.356194496154785
angle_increment: 0.004363323096185923
time_increment: 2.7777778086601757e-05
scan_time: 0.03999999910593033
range_min: 0.0
range_max: 10.0
ranges: [0.251274436712265, 0.251274436712265, 0.251274436712265, 0.251274436712265, 0.251274436712265, 0.251274436712265, ......

$ rviz2

robotpilot · 2018-08-17T05:20:58Z

[successful case]

I hope this test will help you with your work. Based on the comments mentioned above, I ran the static_transform_publisher node to connect the world tf and the laser tf. I was able to check the laser value as shown in the attached figure below.

$ ros2 run hls_lfcd_lds_driver hlds_laser_publisher

$ ros2 topic echo /scan

header:
  stamp:
    sec: 1534483228
    nanosec: 725575168
  frame_id: laser
angle_min: 0.0
angle_max: 6.2657318115234375
angle_increment: 0.01745329238474369
time_increment: 2.9909999284427613e-05
scan_time: 0.0
range_min: 0.11999999731779099
range_max: 3.5
ranges: [1.3600000143051147, 1.4429999589920044, 1.5329999923706055, 1.5880000591278076, 1.5440000295639038, 1.5499999523162842, 1.534000039100647,......

$ ros2 run tf2_ros static_transform_publisher 0 0 0 0 0 0 world laser

$ rviz2

shiveshkhaitan · 2019-02-06T17:06:57Z

The error persists in crystal as well. This would probably be fixed after this PR is merged. I could get Laser scans and Map in both the frames after implementing message filters.

jacobperron · 2019-08-07T19:05:49Z

Since #375 has been merged, following the steps to reproduce, I can now see the laser scan in all frames. But, I am unable to see the map when switching to the frames that are not static wrt world, ie. single_rrbot_hokuyo_link, single_rrbot_camera_link, single_rrbot_link2, and single_rrbot_link3.

I get the error:

[ERROR] [rviz2]: Lookup would require extrapolation into the future.  Requested time 1565204390.71718 but the latest data is at time 1565204390.71718, when looking up transform from frame [single_rrbot_hokuyo_link] to frame [world]

emersonknapp · 2019-10-10T21:30:02Z

But, I am unable to see the map when switching to the frames that are not static wrt world

@jacobperron @wjwwood do you think the map display issue should be tracked as a new issue, and this one closed out since the specific case of "laser scans not showing" has been resolved?

wjwwood · 2019-10-10T23:48:01Z

I mean we can close this and open a new one, but the issue @jacobperron is describing makes me think that there is some lingering issue with #375... It should not even try to extrapolate into the future, in fact the data should never be delivered unless it could be transformed without extrapolation.

emersonknapp · 2019-10-11T21:19:27Z

Ok! Just wanted to make sure we were tracking the right thing

Instead of the current time, use Time(0) to get the latest available transform as a fallback. This is the same logic that is applied in RViz from ROS 1. Resolves #332 Signed-off-by: Jacob Perron <jacob@openrobotics.org>

jacobperron · 2019-11-27T00:26:21Z

See #483 for a fix.

Instead of the current time, use Time(0) to get the latest available transform as a fallback. This is the same logic that is applied in RViz from ROS 1. Resolves #332 Signed-off-by: Jacob Perron <jacob@openrobotics.org>

wjwwood added the bug Something isn't working label Jun 28, 2018

wjwwood added the help wanted Extra attention is needed label Jul 11, 2018

Martin-Idel-SI mentioned this issue Jul 11, 2018

Fix missing status in laser scan display #335

Merged

chapulina mentioned this issue Aug 21, 2018

[ros2] Add gazebo_ros_ray_sensor ros-simulation/gazebo_ros_pkgs#785

Merged

chapulina mentioned this issue Aug 30, 2018

[ros2] Port diff_drive plugin to ros2 ros-simulation/gazebo_ros_pkgs#806

Merged

Martin-Idel-SI mentioned this issue Oct 9, 2018

High latency in TF propagation #359

Closed

routiful mentioned this issue Oct 30, 2018

Port turtlebot3_simulations to ROS2 ROBOTIS-GIT/turtlebot3_simulations#64

Closed

wjwwood mentioned this issue Dec 12, 2018

[dummy_robot] rviz intermmittently displays lidar data: Lookup would require extrapolation into the future ros2/demos#295

Closed

chapulina mentioned this issue May 7, 2019

Gazebo support (draft) Karsten1987/confbot_robot#19

Merged

routiful mentioned this issue Aug 20, 2019

TB3 build fail at SBC setup (15.1.2) of Micro-XRCE-DDS-Agent Install Fail ROBOTIS-GIT/turtlebot3#461

Closed

robotpilot mentioned this issue Aug 26, 2019

TB3 for ROS 2 Dashing Diademata ROBOTIS-GIT/turtlebot3#460

Closed

28 tasks

jacobperron self-assigned this Oct 14, 2019

jacobperron mentioned this issue Nov 27, 2019

Fix map display for moving TF frame #483

Merged

wjwwood closed this as completed in #483 Dec 2, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

laser scans not showing when fixed frame is not equal to the laser scans frame id #332

laser scans not showing when fixed frame is not equal to the laser scans frame id #332

wjwwood commented Jun 28, 2018

Martin-Idel-SI commented Jun 29, 2018 •

edited

Loading

wjwwood commented Jun 29, 2018

wjwwood commented Jun 29, 2018

Martin-Idel-SI commented Jun 29, 2018 •

edited

Loading

Martin-Idel-SI commented Jul 2, 2018 •

edited

Loading

Martin-Idel-SI commented Jul 3, 2018 •

edited

Loading

robotpilot commented Aug 17, 2018

wjwwood commented Aug 17, 2018

robotpilot commented Aug 17, 2018

robotpilot commented Aug 17, 2018

robotpilot commented Aug 17, 2018

shiveshkhaitan commented Feb 6, 2019 •

edited

Loading

jacobperron commented Aug 7, 2019

emersonknapp commented Oct 10, 2019

wjwwood commented Oct 10, 2019

emersonknapp commented Oct 11, 2019

jacobperron commented Nov 27, 2019

laser scans not showing when fixed frame is not equal to the laser scans frame id #332

laser scans not showing when fixed frame is not equal to the laser scans frame id #332

Comments

wjwwood commented Jun 28, 2018

Martin-Idel-SI commented Jun 29, 2018 • edited Loading

wjwwood commented Jun 29, 2018

wjwwood commented Jun 29, 2018

Martin-Idel-SI commented Jun 29, 2018 • edited Loading

Martin-Idel-SI commented Jul 2, 2018 • edited Loading

Martin-Idel-SI commented Jul 3, 2018 • edited Loading

robotpilot commented Aug 17, 2018

wjwwood commented Aug 17, 2018

robotpilot commented Aug 17, 2018

robotpilot commented Aug 17, 2018

robotpilot commented Aug 17, 2018

shiveshkhaitan commented Feb 6, 2019 • edited Loading

jacobperron commented Aug 7, 2019

emersonknapp commented Oct 10, 2019

wjwwood commented Oct 10, 2019

emersonknapp commented Oct 11, 2019

jacobperron commented Nov 27, 2019

Martin-Idel-SI commented Jun 29, 2018 •

edited

Loading

Martin-Idel-SI commented Jun 29, 2018 •

edited

Loading

Martin-Idel-SI commented Jul 2, 2018 •

edited

Loading

Martin-Idel-SI commented Jul 3, 2018 •

edited

Loading

shiveshkhaitan commented Feb 6, 2019 •

edited

Loading