Marking and clearing for range sensor layer

[bit-pirate]

I'm using the range sensor layer together with the voxel layer. After hacking around a bit, I wonder how to implement this.

As far as I understand the currently implementing logic follows the CostmapLayer::updateWithMax behaviour. However, this does not allow to clear obstacles added by another layer.

An implementation similar to CostmapLayer::updateWithOverwrite allows the clearing, but does not play nicely with the clear costmap recovery behaviour.

Any suggestions how to implement marking and clearing for the range sensor layer?

Before I further attempt new implementations, I'll wait for #13 to be answered.

[DLu]

Does the clear_costmap recovery behavior set all of the values to 0 rather than 50/50 probability?

[corot]

Actually, seems like lear_costmap recovery behavior doesn't affect this layer (see PR #19)

[corot]

Apart to the interactions with other sensors that @bit-pirate describes, I have a much simple problem: the current implementation only uses readings for clearing up to max_range, but to my understanding values above up to +inf should be considered. Otherwise you are forced to modify the driver that provides the readings so all readings are max_range at maximum (what contradicts REP-117, assuming it applies to range finders!).

I'll submit my changes as a PR if you agree.

[DLu]

That is a valid point. I am not always up to date on the sensor standards (i.e. REP-117). PR welcome.

[DLu]

Actually, it might already be handled. I'm testing now.

[DLu]

Nevermind. Infinite ranges are ignored completely: https://github.com/DLu/navigation_layers/blob/hydro/range_sensor_layer/src/range_sensor_layer.cpp#L228

@AlexReimann - what was the intended effect of the parameter clear_sensor_cone?

[AlexReimann]

It comes originally from here:
b702525
Specifies to clear or not to clear. Mostly used for the clear_on_max_reading_ parameter.

Yeah, it seems this is my fault, the implementation before clears out stuff when range >= max_range.
The reason I changed that was the comment in the range message:

#(Note: values < range_min or > range_max
# should be discarded)

But I actually think REP-117 doesn't say values above max_range should clear. It just defines the usage of +/- Inf and NaNs. The reference implementation even states !isfinite(value) && value > 0 for No objects detected in range (so only +Inf is valid for objects out of range).

The use case / reasoning of @corot makes sense though.

[bit-pirate]

But I actually think REP-117 doesn't say values above max_range should clear

I second that. REP-117 says that readings above max_range (or below min_range) should not be taken into account (discarded).

Hence, the range_sensor_layer should not use this information for anything - including clearing - since those readings above max_range cannot be trusted. You might end up clearing areas, where there are obstacles.

(what contradicts REP-117, assuming it applies to range finders!).

@corot I don't see a contradiction here.

[corot]

Probably you are right, current implementation conforms to REP-117. But I still think it make sense use values above max range until +inf to clear. Is a matter of interpretation of what max_range actually means: "trustable detection limit" (for me) or "useful information limit" (for REP-117)

Anyway, I just faked my driver to bound all readings within the min/max ranges limits. Is a bit weird but it works.

[bit-pirate]

I don't think there is need to "fake" things. If you you like to trust
readings beyond your current max_range, why don't you just increase your
max_range?

In our case, we use PSDs and sonars, for which we set the limits from their
specification. We could set them a bit higher, but then we also increase
the chance of wrong readings.

On 21 May 2015 at 06:25, Jorge Santos Simón notifications@github.com
wrote:

Probably you are right, current implementation conforms to REP-117. But I
still think it make sense use values above max range until +inf to clear.
Is a matter of interpretation of what max_range actually means: "trustable
detection limit" (for me) or "useful information limit" (for REP-117)

Anyway, I just faked my driver to bound all readings within the min/max
ranges limits. Is a bit weird but it works.

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

Innovation Team Leader
Yujin Robot
Seoul, Republic of Korea
Twitter: https://twitter.com/yujinrobotinno
Website: http://inno.yujinrobot.com
Email: marcus.liebhardt@yujinrobot.com
Phone: +82-70-46577073

[corot]

Problem comes because I use sonars with a quite wide fov, and also many noisy readings, so I must restrict to use the for close range obstacle avoidance. If I let the factory stated 6 m range, I get a completely meshed up costmap, with all narrow passages blocked. Setting max range to something between 1 and 2 m, and letting higher ranges to clean works fine.