Stuff being added to global costmap?

[lucasb-eyer]

By now, Karl doesn't want to come near my desk anymore, because the global costmap contains high-cost blobs at the location of that topological node. I don't know how they got there, they don't appear in the local costmap (I render them in different colors, so I'm sure about that) and they don't get cleared when I push him there.

What could possibly add points to the global costmap? I'm confused.

[nilsbore]

Hey, that sounds weird. The head camera only adds stuff to the local costmap so that can't be it. The only thing I can think of is that it was in the recorded map to begin with.

[lucasb-eyer]

No, in today's started-from-scratch system, it isn't there. I really cannot explain it either, but I also really don't know much about costmaps. Will post pictures when/if it happens again.

[lucasb-eyer]

Wait, I see an obstacle layer in the global costmap in rqt_reconfigure, is this correct? That's the layer where stuff is added and lingers at the end of the day.

[bfalacerda]

yeah, i was just checking and we do have the obstacle layer on the global costmap also.

It kind of makes sense, if you can see your goal and you know there's something there, there's really no use on generating a global plan there, use dwa to follow it, and then just failing when you're close because the dwa planner doesn't find a path anymore

On the other hand global planner failures are pretty annoying and happen a bit too much I think. Another thing to take into account when tackling strands-project/strands_movebase#24

[lucasb-eyer]

if you can see your goal and you know there's something there, there's really no use on generating a global plan there

Actually, that's exactly one thing we've been complaining about! I think he still should, because often your goal is just an intermediate node in the topological graph and, even if the node itself is covered by an obstacle, the robot would still get close enough to enter the influence area and then plan around the obstacle to the next node. At least that's what we'd hope for.

[nilsbore]

TBH, I've also thought about the rationale behind this sometimes (wasn't me who added that part). We still have the clear_costmap recovery behaviour activated though (if the defaults haven't changed in move_base) and that should clear everything further away than 3m from the robot at global planner failure?

[bfalacerda]

@lucasb-eyer that is a really good point and I completely agree that what you described is the kind of behaviour we should be observing from the robot. I already talked with @Jailander about it a couple of times, and me and @hawesie were just discussing it today when we were coming back from the library.

However, I don't think the costmaps level is appropriate to be thinking about that issue. IMO, our system should worry about it at the topological navigation level: for most of the intermediate nodes (door passing or docking nodes for example are a bit of an exception), we should be planning to go to areas of the environment, i.e., influence areas of nodes, and not to exact poses. How to do this using the move_base framework is still something we need to look at. One way to do it might be dynamically reconfiguring the move base goal error params, but we have to check how the global planner behaves when we give it very coarse goals. The reason we didn't tackle this issue yet is pretty much lack of time, but I agree that it needs to be done.

@nilsbore , regarding move_base's own clear costmaps recovery, I've never seen it clearing anything TBH, so right now I think it's pretty useless. I think there are a couple of params we can play with there, maybe we can get it a bit better. Also, it would make more sense to have our hard costmap clearance (that I had in monitored nav for some days but then took out because it looked like it was creating some move_base stability issues) included directly as a move_base recovery. I didn't have the time to see how you can implement those though. That's why I added it in the monitored_navigation state machine instead.

Bottom line, there is still a lot to do here and everyone's help is welcome :)

[bfalacerda]

clearing costmaps now works, closing