Revision history [back]

It looks like the costmap is smearing the laser scan because it doesn't quite correctly account for the amount of time that it takes to actually rotate the scanner and capture the scan. This probably isn't noticeable on faster scanners or slower robots, because the distortion is lower.

rviz is correct, and waits for transforms for the entire duration of the scan to arrive before attempting to transform it.

costmap2d waits for a fixed window of transforms to arrive before attempting to transform the scan. If your scan took longer to acquire than the fixed time that the costmap has hardcoded, then it will attempt to transform before all of the transforms have arrived, and will probably smear the scan.

If you're comfortable building navigation from source, you can manually increase the tolerance here: https://github.com/ros-planning/navigation/blob/ada542feae238cc85eeab9944cc39e37eee93481/costmap_2d/plugins/obstacle_layer.cpp#L179 to something at or above your scan time, rebuild navigation, and see if that helps. (For a 3Hz sensor, a tolerance of 0.34 should be about right).

If that fixes the issue, open a ticket against navigation's bug tracker.

For reference, the section of rviz that computes the correct tolerance is https://github.com/ros-visualization/rviz/blob/1804cbf63241dcf174b1b76449a302e4321c50d8/src/rviz/default_plugin/laser_scan_display.cpp#L87-L93