Updating PlanningScene after clearOctomap

[simonschmeisser]

Description

We use the following code to clear the Octomap:

m_planningSceneMonitor->clearOctomap();

// TODO: octomap is not updated visually with planningSceneMonitor->clearOctomap().
//       This workaround fixes the problem, but often causes a crash
planning_scene_monitor::LockedPlanningSceneRW ps(m_planningSceneMonitor);
    m_planningSceneMonitor->triggerSceneUpdateEvent(planning_scene_monitor::PlanningSceneMonitor::UPDATE_SCENE);

but shouldn't this update be triggered internally here?
https://github.com/ros-planning/moveit/blob/kinetic-devel/moveit_ros/planning/planning_scene_monitor/src/planning_scene_monitor.cpp#L498

void planning_scene_monitor::PlanningSceneMonitor::clearOctomap()
{
  octomap_monitor_->getOcTreePtr()->lockWrite();
  octomap_monitor_->getOcTreePtr()->clear();
  octomap_monitor_->getOcTreePtr()->unlockWrite();
}

Also I'm not sure about the locking necessary

I will provide a PR once I have the time and some feedback here

Your environment

• ROS Distro: Kinetic

[v4hn]

Hi Simon, Thanks for contributing back! Looks like you're cleaning up part of your code base at the moment? :) `PlanningSceneMonitor::clearOctomap` was added by @hersh two years ago to forward this functionality to the move_group and provide a ROS service to call it in fad82fb . Nobody touched it since. I assume it was more important to get the functionality and less so to get it 100% correctly integrated.

On Tue, Jan 31, 2017 at 07:46:59AM -0800, Simon Schmeisser wrote: but shouldn't this update be triggered internally here?

Yes, I believe so. This is an update to the scene, so it should report the change. You're right.

Also I'm not sure about the locking necessary

What makes you think this is not necessary? I did not look into the details here yet.

I will provide a PR once I have the time and some feedback here

Cool! :-)

[rhaschke]

Fixed by #3134