# PR2 sees ghost obstacles in tilting laser

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:

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

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 close merge delete

1

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

( 2012-06-23 06:14:53 -0500 )edit

Sort by » oldest newest most voted

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:

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:

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" />
</node>


Note: In Fuerte, the parameter is called incident_angle_correction.

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

more

1

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 (parsec.googlecode.com), package parsec_perception. In parsec_navigation you can find a launch file.

( 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.

( 2012-06-26 02:03:15 -0500 )edit

According to the laser filter wiki http://www.ros.org/wiki/laser_filters/Tutorials/Laser%20filtering%20using%20the%20filter%20nodes#All_in_One_Node:_scan_to_cloud_filter_chain this "offset feature" seems useful for long distance, but not for short range. I'm wondering how you'll reconcile the two?

( 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

( 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).

( 2012-06-26 22:19:54 -0500 )edit

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: https://github.com/uu-isrc-robotics/uu-isrc-robotics-pr2-pkgs/tree/master/good_pr2_local_nav that I've copied from somewhere :-)

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.

( 2012-06-25 22:03:45 -0500 )edit

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.

more

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

( 2012-06-25 22:04:39 -0500 )edit