Ask Your Question

PR2 sees ghost obstacles in tilting laser

asked 2012-06-23 01:16:20 -0500

updated 2014-11-22 17:05:44 -0500

ngrennan gravatar image

A PR2 I've been working with a while ago has the problem that the tilting laser reports erroneous obstacles to the right and left of the robot, which leads to "ghost obstacles" and messes up navigation. The problem can be seen in the following screenshot:

image description

Note the straight lines on the ground to the right and left of the PR2. They seem to lie above the ground, so they are not caught by the ground removal. The further the points are from the robot, the higher above the ground they are. It looks as if the Hokuyo reported not a straight line, but a bent one.

Did anybody else see this problem? Any idea what went wrong?

Here's some more pictures:

resulting problems in navigation caused by the straight-line artifacts

Resulting problems in navigation caused by the straight-line artifacts

A photo of the actual scene

A photo of the actual scene. The ground here is pretty cluttered, but the same problem exists when there is nothing on the ground at all.

edit retag flag offensive close merge delete



I don't have a solution but I can tell you that I've seen similar behavior on multiple other PR2s.

Dan Lazewatsky gravatar image Dan Lazewatsky  ( 2012-06-23 06:14:53 -0500 )edit

3 Answers

Sort by » oldest newest most voted

answered 2012-06-26 00:15:45 -0500

updated 2012-06-26 08:42:47 -0500

Note: solved, see update at the end

I've found the root of the problem. This seems to be a bug in laser_filters. I tried reproducing this in Gazebo to rule out hardware problems, and this is what I get when visualizing the /tilt_scan_shadow_filtered topic:

transformed point cloud

The blue points on the side have an average height of 0.003 m, the red ones in the middle have an average height of -0.018 m. In Gazebo, all points are still removed by sac_ground_removal, but on the real PR2 I've been working with only the red/yellow/green points in the middle are removed, and the blue ones remain. This is exactly what I am seeing.

This is clearly a bug in the scan_to_cloud_filter_chain from laser_filters; I tried removing everything from the filter chain except the LaserScanAngularBoundsFilter, and the problem is still there. The "dent" in the point clouds is not present in the original scans:

tilt scan

How to reproduce (Electric):

roslaunch pr2_gazebo pr2_empty_world.launch
roslaunch pr2_2dnav_local pr2_2dnav.launch

Update: It's not a bug, it's a feature. To disable it, set the parameter use_hack of the scan_to_cloud_filter_chain node to false, for example like this (in pr2_navigation_perception/lasers_and_filters.xml):

<node pkg="laser_filters" type="scan_to_cloud_filter_chain" respawn="true" machine="c2" name="tilt_shadow_filter">
  <param name="use_hack" value="false" />

Note: In Fuerte, the parameter is called incident_angle_correction.

This solved the problem on the real (not simulated) PR2.

edit flag offensive delete link more



The sac_ground_removal node and the whole laser pipeline seems to be pretty out-dated. I guess the only node that hasn't been ported to PCL. In the parsec repo you can find a re-implementation (, package parsec_perception. In parsec_navigation you can find a launch file.

Lorenz gravatar image Lorenz  ( 2012-06-26 00:26:38 -0500 )edit

Thank you Lorenz, I wasn't aware of that! For the moment I hope that I have found the solution, but if I have to dig deeper, it's good to know there's a better/cleaner alternative to the laser pipeline.

Martin Günther gravatar image Martin Günther  ( 2012-06-26 02:03:15 -0500 )edit

According to the laser filter wiki this "offset feature" seems useful for long distance, but not for short range. I'm wondering how you'll reconcile the two?

weiin gravatar image weiin  ( 2012-06-26 15:28:57 -0500 )edit

of course, i understand the PR2 tilt laser isn't used primarily for long range navigation since it has the base laser. but I'm just wondering if only one tilt laser is sufficient to do both navigation and short range obstacle avoidance

weiin gravatar image weiin  ( 2012-06-26 15:32:42 -0500 )edit

@weiin: I think if you're interested in that, it would be best to open a new question (link to this one if it's relevant).

Martin Günther gravatar image Martin Günther  ( 2012-06-26 22:19:54 -0500 )edit

answered 2012-06-25 08:58:59 -0500

I've had this problem for a long time, even on flat surfaces. Many people have reported the same. There are two approaches you can follow:

  • Use dynamic_reconfigure and change some of the parameters (there's a z_threshold filtering one you can play with)
  • Copy some "good" set of parameters.

You can find one at: that I've copied from somewhere :-)

edit flag offensive delete link more


Thanks, we'll try upping the z_threshold filtering. It's rather a workaround than a solution, but it should work. I don't think the pr2_local_nav parameters have anything to do with it, because the errors in navigation are an aftereffect of the incorrect laser readings.

Martin Günther gravatar image Martin Günther  ( 2012-06-25 22:03:45 -0500 )edit

answered 2012-06-25 11:39:55 -0500

jbohren gravatar image

Check the NTP synchronization between the computers involved in the ROS graph. Sometimes this can cause problems when TF transforms pointcloud data from a quickly moving source.

edit flag offensive delete link more


Thanks, we'll check the NTP synchronization too and report back here. This looks promising.

Martin Günther gravatar image Martin Günther  ( 2012-06-25 22:04:39 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2012-06-23 01:16:20 -0500

Seen: 1,100 times

Last updated: Jun 26 '12