Re: [ompl-users] Re-using data from previous planning requests.

[Mark M. <mm...@ri...>]

Hi Yoann,

My answers are below inline.

Mark



> On Sep 28, 2016, at 7:23 AM, Yoann Solana <ys...@la...> wrote:
> 
> Hi all,
> 
> We are working on the implementation of research work about dual-arm manipulation. Our goal is to develop in Moveit a new functionality able to execute complex closed kinematics chain motions in a cluttered environment. For now, we are able to plan motion with the RRT planner. However, the workspace is very complex, so that planning requests are almost impossible to solve in a short time (1-2s). Therefore, we want to take advantage of multi-query planners like PRM or SRS to compute offline a roadmap of the workspace in order to efficiently perform a motion request later.
> 
> In previous posts (https://sourceforge.net/p/ompl/mailman/message/32657097/ <https://sourceforge.net/p/ompl/mailman/message/32657097/>, https://sourceforge.net/p/ompl/mailman/message/35074389/ <https://sourceforge.net/p/ompl/mailman/message/35074389/>), Mark Moll explained that is was not possible to restart the planner using a previously constructed  roadmap without a lot of work in the code. However, he proposed experienced based planners. 
> 
> I read the article "Experience-Based planning with Sparce Roadmap Spanners" and the LightningThunder demo. I'm thinking about using the Thunder framework inside Moveit, but I need to be sure if it will be in accordance to our requirements.
> I have several question about the Thunder framework:
> _ The exp-based planning is suited for robots with large number of invariant constraints. So, for our case, additional constraints generated by closed kinematic chains can be easily encoded in the experience database. This will lead to have a robust database. Am I right?
> 

Yes.
> _ I see the size of the data base have a kind of theoretical limit. However, can I be sure that the database will have a size limit, even after months of running?
> 

The database is *guaranteed* not to grow indefinitely. This is because it is using the spanner properties of the underlying SPARS2-based planner. By changing the planner parameters you can control how sparse the roadmap (and how large the database) will be. We can’t predict what the size of the database will be in the limit, though.
> _ Our experimentation consists in planning motion for several objects to manipulate. During the experimentation the start and goal poses of the objects will be always the same for each object. The data base of Thunder grows at each time the planner from scratch (PFS) find a solution before the retreive-repair planner (RR). However, when the database contains the path, the PFS has a low probability to find a path first and maybe to improve the quality of the database in order to have more optimal path for future planning request. So, is it possible to force the PFS to generate trajectory in order to improve the database?
> 

I am a little confused. PFS and RR run in parallel threads. Whichever finds a solution first will terminate the other thread.
> _ Last question, I see the experimentation in the article was perform with Moveit/OMPL. Is it possible to have more documentation about the implementation in Moveit?
> 
That’s a great idea. Dave Coleman (cc-ed) has written most of this code. I hope he can find some time to write some instructions on how to use Thunder/Lightning with MoveIt!.