new nav params

[bfalacerda]

also gets the clear costmap recovery from move base to work again

[nilsbore]

We have to revert the resolution of the local_costmap or increase the resolution of the obstacle cloud before merging this.

[bfalacerda]

i'll revert the resolution

[bfalacerda]

done. please test before merging anyway

[nilsbore]

What's the reason for having a slower publishing of the global costmap? Computational cost?

[nilsbore]

And the the slower planning frequency? I remember trying slower ones but it made the robot a bit unresponsive. Well, I'll try it out now=P.

[bfalacerda]

@lucasb-eyer can you give this a try in your hardcore environment?

[nilsbore]

I tried it here and the removal of the local costmap seems to have resulted in better manoeuvring in tight spaces. It doesn't solve everything though, door passing is still not 100% (which it used to be, but maybe that's because the robot was too aggressive).

Thing is, I haven't really seen this going against obstacles except for when the robot has a hard time planning path, e.g. passing through a door. So if more people can test that's welcome.

[lucasb-eyer]

I'm out of town for the rest of the week and I think @Pandoro is busy with a deadline. So won't be able to test before Monday at earliest, sorry.

[nilsbore]

Hmm, another thing we might try is to increase the observation_persistence parameter in the obstacle layer. As I understand it, it determines if we buffer the observations that are added to the costmap or throw old ones away if we get a new one before we update the costmap. I think it makes sense to add all of the observations we get, since the subsampling node is adapted to have a similar publish frequency as the update rate of the costmap. If we're unlucky, we might throw away every other sample. So if we have an observation_persistence at the same value as the update rate of the costmap, we should integrate all of the measurements we get. Right now, observation_persistence is set to 0, which means that we only use the latest measurement that we got when we update the costmap.

This is only needed for the chest camera I think, integrating all laser scans might be too costly.

[bfalacerda]

will this help have extra clearing, or just add more obstacles to the costmap?

[nilsbore]

That's the question=P. I would guess that a higher update rate (which this would result in) could help clear more obstacles e.g. when people are walking by the robot on the sides as it's moving.

[bfalacerda]

ok, so if we keep all of them while the robot is moving we can think of it as a way to increase the fov of the observation, as we're adding two readings done is slightly different positions to the costmap. Is that it?

Can you do some testing on it?

[nilsbore]

Yeah, more or less. The buffered pointcloud should still be inserted in the correct position since the costmap should use the timestamp and tf to transform it. It's really hard to test this but I'll do my best, I guess I can slow down the update of the costmap more to see if this works as expected.

[bfalacerda]

i just added a commit fixing our use of move_base's clear costmap recovery and putting all the move base params in a yaml file to make it more tidy

[nilsbore]

Ok, I have some time now and I will try this a bit more. But I don't see any problems with the proposed parameter changes.

Will also look at removing chest camera from global costmap and see what effect increasing the obstacle persistence has.

[bfalacerda]

@lucasb-eyer did you have time to have karl go around with these params?

[nilsbore]

This looks good, door passing with move_base works a bit better and parameter changes look good. It would be nice with feedback from @lucasb-eyer before merging.

[vonovak]

We tested the params today and it works better!

[bfalacerda]

i'm merging this then. can we re-release it?

[lucasb-eyer]

More info: @vonovak is a student working on Karl for me and @Pandoro. He did try to navigate to a difficult place through a narrow corridor, which invariably failed before these changes, but works nicely with these changes. We have yet to let Karl run around by himself a whole day with this.