Points on costmap layer after inflation layer might get inflated in edge cases about navigation2 HOT 6 CLOSED

Have you looked into why this is happening, codewise?

@AlexeyMerzlyakov was poking around here in the last 2 years, maybe he has some insight?

from navigation2.

I took a quick look into the code but sadly could not find anything yet. I will see if I can find some time to dive deeper later this week.

from navigation2.

From a quick scan: https://github.com/ros-planning/navigation2/blob/main/nav2_costmap_2d/plugins/inflation_layer.cpp#L216-L242

We find the costs in the master grid (i.e. all of them) adding in a margin for the inflation radius so that obstacles outside of the costmap have their inflations show up before being fully visible. That master grid includes all values, not just those below it.

This is actually one of the main reasons we have the costmap filters API separate from the costmap layers.

Reason for having a layer after the inflation_layer is that we have our own implementation of the keepout zones and we have wanted to inflate those areas bit differently.

It seems like that would meet you need as well.

from navigation2.

Thanks for quick responses and the suggestion. I was looking into this a bit today. Couldn't get much out of it yet, as I was bombarded with other things the whole day.

I believe we are resetting the combined_costmap before passing it to the plugins at https://github.com/ros-planning/navigation2/blob/main/nav2_costmap_2d/src/layered_costmap.cpp#L217.
Assuming that I have not misunderstood how the iterator on the L218 works we should be going through the plugins in the order we added to the plugins_ array and that order is the order which they are listed on the config.
Based on that we should not have the data of the layer defined after inflation when we are on updating costs on inflation_layer. Or am I missing something?

I also gave a try to the filters as you suggested. I added the Keepout Filter to my global costmap and added publishing of the info message to our implementation and got it to work. Looks that we should able to use the filters instead. Have to do a bit more testing on that. And maybe write a implementation without the FilterInfoCallback layer so we do not need to add dependency to nav_msgs to the piece of our code which handles the "keepout" zones.

from navigation2.

Based on that we should not have the data of the layer defined after inflation when we are on updating costs on inflation_layer. Or am I missing something?

Look at the link to the inflation layer. It looks at the master_grid - ie the combined costmap. You're right to say that for a given iteration, the inflation layer wouldn't see data above it -- but the very next iteration then it would. What you're seeing is the inflation of obstacles marked in the global map the cycle after they're marked, not the same one. I believe.

Looks that we should able to use the filters instead.

Good 😄 I think that's actually the reason why we added the costmap filters as a separate object: to overcome this exact issue.

And maybe write a implementation without the FilterInfoCallback layer so we do not need to add dependency to nav_msgs to the piece of our code which handles the "keepout" zones.

As is your right, note that the actual costmap filter API does not require it. Our implementations happen to use it in order to generalize the keepout/speed/binary/etc information to be encoded arbitrarily. If you know your exact encoding and its never going to change, no need to overcomplicate your life, I suppose.

This good to close?

from navigation2.

Right, seems that I have misunderstood the ResetMap function. Thank you for the explanations and tips!

from navigation2.