Obstacles persist in local costmap even after they move out

[Hans Forsberg]

Hi.

My robot is finally working with AMCL, (Thanx to ROS-By-Examble 1 & 2 !!) but with one tricky issue. Obstacles persists in local cost map even after they dissapeared

WHEN THE NEATO XV-11 LIDAR IS 'LOOKING OUT OF RANGE BEHIND' the removed obstacle.

This is correct, since the the reported distance from the XV-11 lidar when 'measuring out of range' is 0.0  So, no laser-data can report that the space is clear again...

-But, what is the best practice to handle this?

-Other XV-11 users, do you have the same issue? Does your XV-11 lidar also report 0.0 when 'out of range' ?

-Do i miss any parameter setting ?

Attached two images. On the 'second' i have drawn the 'field of view' of the lidar due to a glass area. You cab see the inflated obstacles still there, but without 'scan-dots'.

While the lidar reports distance 0.0 in this region it cant clear the obstacles.

Any tips or hints ?

Best regards 

Hans Forsberg

 

[Patrick Goebel]

Hi Hans,

There is a good discussion on just this issue on answers.ros.org.  Basically, when the LIDAR's ray trace passes through an area where the obstacle used to be, it has to return a valid range value beyond the last known position of the obstacle before the costmap will be cleared.  As the thread on answers.ros.org suggests, using a laserscan range filter is one way that people have gotten around the problem.  In this case, a range filter will take all 0.0 values and turn them into max_range + 1.  Elsewhere I have see someone suggest that instead, the filter should actually turn the 0.0 values into max_range - 1 since this is still a valid range value unlike max_range + 1 which by definition is invalid.

This solution does have a drawback: sometimes the LIDAR will return 0.0 values from a non reflecting object such as a black leather sofa or someone's black pant legs.  In this case, application of the range filter to solve the first problem might cause the robot to run into other obstacles it does not see...

--patrick

--
You received this message because you are subscribed to the Google Groups "ros-by-example" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-by-exampl...@googlegroups.com.
Visit this group at https://groups.google.com/group/ros-by-example.
For more options, visit https://groups.google.com/d/optout.

-- 
The Pi Robot Project
http://www.pirobot.org/wordpress

[Hans Forsberg]

Thank you. You described just what i thought and my worries. I'm also slghtly worried about the issue with minimum range for the lidar, since i think this state also reports zero values. This state visshet is easiee to handle, in my case, the robot is quite big, being a Robotic lawnmower chassis, integrating ,,SLAM and Ultra Wide Band and Google Tango VIO postioning systems, and minimum range will be restricted by the robots form factors. 

Reading about the XV-11 driver, IT seems like there are some error codes from the  XV-11 data indicating out of range and some other states, but maybe no one has predicted these issues in the driver code. 

I'll have a go with the laser filter, my Idea was to set the 0 values to Max range plus something very big....to more or less get rid of them .......

Once again. Thank you for your books, really well invested money and an honor to get personal coaching from You

Best regards 

Hans Forsberg

You received this message because you are subscribed to a topic in the Google Groups "ros-by-example" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ros-by-example/HNQBI9NUHcI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ros-by-exampl...@googlegroups.com.

[Patrick Goebel]

Hi Hans,

Thanks for the nice feedback!  Sounds like a very interesting project you are working on.  If you get the LIDAR thing figured out and have the time, please post back to the list how you did it.  (Unless your work is proprietary of course.)

Good luck,
patrick

[Hans Forsberg]

But wait a moment. The suggested solution is to convert my out-of range values (currently reported as 0.0) to MAX Range +1....

Theese values will be considered invalid by ROS...but then, will there be any 'raytracing' through the 'frozen' obstacles this way ? Eill the 'frozen' obstacles be cleared this way?

Is it possible to have obstacles cleared in the local costmap over time...that is, each obstacle has to be 'refreshed'  bý new valid laserscan continously, otherwise the will 'die'....

How do you solve this issue with more advanced lidars like hokoyu  and Sick?

Hans

[Raffi Zack]

I was the one in that discussion who had issues with using Max Range + 1 and instead used Max Range - 1 (or minus some small value) in order to resolve the problem. So for me, making the out-of-range value less than Max was the solution.

[Patrick Goebel]

Hi Raffi and Hans,

Yes, it was Raffi's suggestion that I must have come across earlier.  Assuming the range measurements are in meters, you could subtract something like 0.01 which would be 1 cm.

--patrick

On 04/13/2016 11:39 AM, Raffi Zack wrote:

I was the one in that discussion who had issues with using Max Range + 1 and instead used Max Range - 1 (or minus some small value) in order to resolve the problem. So for me, making the out-of-range value less than Max was the solution.

On Wed, Apr 13, 2016 at 7:21 AM, Hans Forsberg <hfo...@gmail.com> wrote:

But wait a moment. The suggested solution is to convert my out-of range values (currently reported as 0.0) to MAX Range +1....

Theese values will be considered invalid by ROS...but then, will there be any 'raytracing' through the 'frozen' obstacles this way ? Eill the 'frozen' obstacles be cleared this way?

Is it possible to have obstacles cleared in the local costmap over time...that is, each obstacle has to be 'refreshed'  bý new valid laserscan continously, otherwise the will 'die'....

How do you solve this issue with more advanced lidars like hokoyu  and Sick?

Hans The Pi Robot Project http://www.pirobot.org/wordpress

[Hans Forsberg]

Thanx!

Ok but that must mean that 'ghost obstacles' are introduced, at max-range away from the robot as soon as the laser gets out of range or?

Feels like there is something i'm missing here, maybe in the way the local-cost map handles values and 'invalid values'

How does your robot work in a long corridor, twice as long as the max laser range?

Greetings from Gothenburg SWEDEN

  

 

[Patrick Goebel]

Hello Hans,

That's a good point.  So I went back to the costmap_2d Wiki page and refreshed my memory regarding obstacle parameters.  First of all, the max range of the laser scanner does not appear as a parameter for the costmap--it applies only to the laser scanner itself.  The two parameters relevant to the costmap are obstacle_range and raytrace_range as described below:

~<name>/obstacle_range (double, default: 2.5)

• The default maximum distance from the robot at which an obstacle will be inserted into the cost map in meters. This can be over-ridden on a per-sensor basis.

~<name>/raytrace_range (double, default: 3.0) The default range in meters at which to raytrace out obstacles from the map using sensor data. This can be over-ridden on a per-sensor basis.

Note how the default raytrace_range is greater than the default obstacle_range and you probably always want this to be the case so that a ray can always travel further than the furthest possible obstacle in order to clear it.  However, no matter how far out we make the raytrace_range, an obstacle will not be cleared unless the laser scanner receives a return signal from a point beyond the original obstacle.

So it seems that whatever value you convert your 0.0 scan values to, you will need to make your raytrace_range parameter larger than that value so that the modified values are registered.

I did some experiments with my Kobuki this morning using a Hokuyo laser scanner attached to the front of the Kobuki base.  I placed an obstacle a couple of meters in front of the robot and it was picked up on the costmap.  I then removed the obstacle to see if the robot would clear it from the costmap.  As it turns out, it depended on what was behind the original obstacle.  In one case, there was a black sofa that did not reflect the laser at all so the missing obstacle was not cleared from the map.  Looking at the raw scan values, I saw that the Hokuyo reports either nan or inf instead of 0 for these non returns.  In the second case, I placed the obstacle in front of a white wall.  In this case, the costmap was easily cleared after I removed the obstacle since the wall sent back strong reflection data from the laser.  But even in this case, I could prevent clearing by making the raytrace_range too small.  In other words, if the wall was further away than the raytrace_range, the obstacle would not be cleared unless I moved the robot forward to be inside that range.

Finally, note that the obstacle_range parameter described above prevents the "ghost obstacles"  you mention below from being created.

--patrick

-- 
The Pi Robot Project
http://www.pirobot.org/wordpress