ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

slam_karto marks grid cell underneath real robot as occupied

asked 2016-04-21 11:42:52 -0500

spmaniato gravatar image

updated 2016-04-21 11:48:04 -0500

A picture is worth a thousand words, so here are 3000 words :P

When slam_karto starts (on a real robot, not simulation), it marks a few cells underneath the robot as occupied. In the screenshot below, the red arrow corresponds to the robot's initial pose, i.e. [0 0 0]

image description

In turn, this causes planning to fail, since the robot is in the "lethal cost" region of the global costmap. (I'm actually doing exploration here, using the hector_navigation package, not navigation.)

image description

Looking at the incoming LaserScan messages, there don't seem to be any measurements at such short range (see screenshot below, where the decay time has been set to 30 sec.) The messages' range_min field is 0.06. I'm building the LiDAR driver from source, so I tried increasing that, e.g. to 0.15. But it didn't have any effect on the issue at hand. For reference / comparison, this map's resolution is 0.05

image description

This problem doesn't arise in simulation though. I can't seem to find any relevant parameters I could tune in order to prevent this. How should I go about debugging it?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2016-04-21 13:58:27 -0500

spmaniato gravatar image

updated 2016-04-21 16:10:08 -0500

It looks like the following function in Karto.h

inline const PointVectorDouble& GetPointReadings(kt_bool wantFiltered = false) const

is NEVER called with wantFiltered = true And there is no parameter for adjusting this. Thus, Karto's mapper uses measurements whose range is smaller than the LiDAR's min_range. I think these don't show up in RViz exactly because they are below min_range; RViz probably filters them out.

Edit: I opened a pull request:

PS. The reason this doesn't occur in simulation is because the simulated LiDAR measurements are always between min_range and max_range

edit flag offensive delete link more

Question Tools

1 follower


Asked: 2016-04-21 11:42:52 -0500

Seen: 535 times

Last updated: Apr 21 '16