PRM Saving to disk fails when PRM graph is too large because of ROS's SIGTERM

[pbeeson]

Description

If you have a really large PRM, when you CTRL-C in your ROS terminal (because ROS will eventually escalate to a SIGTERM when move_group is starting to save), the file never gets written.

Your environment

• ROS Distro: [Melodic]
• OS Version: Ubuntu 18.04
• Source or Binary build?
  Source (master) with OMPL 1.6 (master)

Steps to reproduce

Run move_group using roslaunch. Make a really big roadmap by running a planning problem with a timeout for like an hour. Then CTRL-C and see that move_group gets a SIGTERM before it is able to properly write out the graph file.

Expected behaviour

If you do this with let's say planing for 20 seconds, it'll write a nice ~50 MB file because it has time to do so before getting the SIGTERM.

Actual behaviour

When the graph is really large, nothing is written out before the SIGTERM that immediately kills move_group node.

[welcome]

Thanks for reporting an issue. Because we're a volunteer community, providing a pull request with suggested changes is always welcomed.

[pbeeson]

Since this already has ROS hooks in the planner_context_manager.cpp, might I suggest trying to to set up like a ROS timer to similar every N minutes that saves the roadmap to disk in its own thread.

[v4hn]

Could you please add links to the relevant code lines?

It seems more reasonable to me to save roadmaps via a service call than on shutdown.
After all, the move_group node might progress a number of very different scenes over time and only the user knows when the scene changes (and thus the roadmap becomes invalid).

[pbeeson]

This is (the only place) where the roadmap gets saved to disk: https://github.com/ros-planning/moveit/blob/335ba7e7710d2189e98ee769a9688f364a26e330/moveit_planners/ompl/ompl_interface/src/planning_context_manager.cpp#L96

[v4hn]

This is (the only place) where the roadmap gets saved to disk: https://github.com/ros-planning/moveit/blob/335ba7e7710d2189e98ee769a9688f364a26e330/moveit_planners/ompl/ompl_interface/src/planning_context_manager.cpp#L96

:/ Saving files in the destructor only is fragile to begin with if there is no controlled way to destroy the objects... Could I convince you to invest the work and make a ROS service available to store roadmaps from the datastructures? @mamoll should also be interested.

[pbeeson]

The main problem is that the planner isn’t thread safe so if you are saving while updating that roadmap, it blows up.

[v4hn]

The main problem is that the planner isn’t thread safe so if you are saving while updating that roadmap, it blows up.

Sure, but I don't think it is a big deal to add a mutex and have the ros-service wait until planning finished? Mind you, I did not look through the internal structures here as much as you did, so I might be mistaken.

[pbeeson]

I’m fine with a service. I didn’t delve deep enough to know where to add the mutex, only that it is needed.

[simonschmeisser]

+1 for service calls/functions for loading and saving

Is the size of the network unbounded? Are there "self-cleaning" variants? @mamoll