You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 13, 2017. It is now read-only.
"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).
The text was updated successfully, but these errors were encountered:
skohlbr
added a commit
to team-vigir/vigir_manipulation_planning
that referenced
this issue
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).
The text was updated successfully, but these errors were encountered: