proper value for aggressive costmap reset distance

[bfalacerda]

I think the current value is an accident waiting to happen:

1. robot passes next to a wheelchair and gets stuck shortly after
2. current aggressive costmap reset clear everything the robot doesn't see, including the chair
3. robot can now happily rotate and crash into the wheelchair

So, this version takes into account the robot's tail when clearing the costmaps. I was reminded of this param due to https://github.com/strands-project/strands_movebase/issues/62#issuecomment-154044167, it might be that with this the robot isn't able to slightly move anymore, and move_base won't get stuck in the infinite dwa fails - costmap cleared - dwa moves just a bit - dwa fails loop anymore. Regardless, I think this should be merged, for safety issues

[cdondrup]

Old problem, this is not used in simulation.

[bfalacerda]

I think it is, I see this in the config you printed here:

aggressive_reset:
  layer_names: [obstacle_layer]
  reset_distance: 0.0

[bfalacerda]

ah, i should change this one:

https://github.com/strands-project/scitos_2d_navigation/blob/hydro-devel/scitos_move_base_params/move_base_params.yaml

I also noted that the scitos_2d_nav have the params from @kunzel. We need to unify this somehow, I think we should look for a solution with a single set of files

[marc-hanheide]

I think this makes sense, but it will also keep the robot stuck, when it has some spurious obstacles still lingering in front of it, right?

[bfalacerda]

If it's really close to the robot I guess it can happen. That's probably why I just set it to 0 the first time. I didn't check if this would be a problem though

[nilsbore]

I think lingering obstacles was the reason for setting this to 0.0, e.g. BHAM had lots of issues with this in the marathon I think? But I thought this was also done by @bfalacerda in a recovery behaviour in monitored_navigation? We have had this discussion before several times. I agree that if we want to have the robot really safe, the aggressive reset should be higher.

[bfalacerda]

I had a recovery behaviour that called the service to reload the costmaps because when we moved to hydro we didn't set the namespace for the costmap clearing within move base correctly, so it wasn't working. Once I realised that and fixed it, I removed the recovery behaviour.

The case where the lingering obstacles were really a problem was when no clearing was in place. I haven't tested how the less aggressive clearing handles it, and I won't be able to do it next week, work travel.

[nilsbore]

If no one objects I'm gonna merge this, we probably want this running on our robot irrespective of how it effects navigation. Potential issues will have to be fixed in other ways.

[bfalacerda]

i was trying to test for lingering objects before merging, but I'm having problems with the 3d obstacle avoidance, looks like there's some topics mismatch that I never seen before. I just started a chat with you on gitter :)

Regarding merging this, I agree that the super aggressive costmap reset shouldn't be a solution for any issue, so we should merge this