Skip to content
This repository has been archived by the owner on Nov 13, 2017. It is now read-only.

Updating/Resetting planning scene octomap is broken once updaters are running #651

Open
skohlbr opened this issue Mar 9, 2016 · 0 comments

Comments

@skohlbr
Copy link
Contributor

skohlbr commented Mar 9, 2016

As also mentioned in https://groups.google.com/forum/#!topic/moveit-users/MFXZWp7_iSQ:

"We tested publishing an empty PlanningScene like you suggested, and it temporarily removed the octomap, but as soon as it got another scan, the entire octomap reappeared. This did destroy the collision matrix as well, so the robot was unable to move."

Instead of resetting the octomap I want to set it to a specific prior map state. I tried using the processOctomapMsg from a custom move_group plugin, but this did not have any observable effect, although the function was clearly called. I then removed my point cloud octomap updater and tried again. This made the correct map appear on startup. As also indicated by the quote above describing the same effect, this appears to be seriously broken with the behavior of processOctomapMsg varying between "not working whatsoever" and "works as expected" depending on a sensor updater running or not.

I haven't fully understood how things interact, but apparently as soon as the updater is running, the planning scene octomap is updated from the updater and other interaction with via the planning scene API ceases to work.

This also appears to be the reason why #495 was introduced (which should not be needed if processOctomapMsg always worked correctly, as then a empty octomap could be used for clearing).

skohlbr added a commit to team-vigir/vigir_manipulation_planning that referenced this issue Mar 9, 2016
otamachan pushed a commit to otamachan/moveit_ros that referenced this issue Oct 22, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant