Closed nilsbore closed 9 years ago
Sorry, but I'm not sure this was a good idea. Sorry for not removing this pull request but I was considering a different solution for this. Basically, this adds some complexity by representing a larger volume in the costmap, meaning I'm not sure if performs as good as the normal height we've been using. I was thinking of doing this optional or something.
Is it possible to revert a merge directly from github?
There is a "Revert" button. Let me try.
"Sorry, this pull request couldn't be reverted automatically. It may have already been reverted, or the content may have changed since it was merged."
Ok, I'll give it a try locally.
sorry... make sure you do it on the most recent version.
I was in the process of releasing it. Let me know when I can.
To my understanding I can't do this without push access directly to this repo, is that correct?
You have to create a PR that reverts your changes from this one. Don't need push rights for that. The automatic revert doesn't work anyway.
Actually, I don't think this merge had any effects, since I deleted all of the files that were changed later on.
So when I try to revert it, nothing happens. The only thing is that it's polluting the changelog.
Yes, that's what I had to do when I merged it... Accepting that you deleted the files in the other pull request. You deleted the files (which I thought make much sense as this was to go into strands_movebase
). So, maybe this is all good?
Yeah, you should be able to release it.
OK, I'll give it a go
This adds an extra obstacle layer in the local costmap called the head_obstacle_layer. This is done to minimize interference with the rest of the nav stack but comes with one big drawback: The head_obstacle_layer cannot clear the obstacle_layer and vice versa. I have not encountered a problem with this during my experiments since the robot can typically go forward after backing down. Also, at G4S there shouldn't be many dynamic obstacles if I'm not wrong. Otherwise, adding it to the normal costmap could have caused performance issues which I am not so keen on introducing at this point=/. Also, the local costmap gets cleared when the robot is more than 4 meter (or is it 2) meters away.
@BFALacerda Should this go in a G4S deployment branch instead?