"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.
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 https://github.com/ros-planning/moveit_ros/pull/495 was introduced (which should not be needed if processOctomapMsg always worked correctly, as then a empty octomap could be used for clearing).