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

[Yoann S. <ys...@la...>]

Hi Mark,


Thank you for your answers.

I have completed and reformulated the remaining question, see below.

>     _ 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.

What I mean is, once a path exists (or almost) in the database, the 
probability for the PFS thread to return a solution first is lower than 
this one for the RR thread. Because a single planning request takes a 
lot of time (20-30s) for this problem. Moreover, in this case the 
database has a low probability to be enriched and improved.
So it is possible to force the PFS thread to work alone (to focuse on 
the learing) some time in order to build a more "optimal" database? If 
yes, Is it possible to do this offline?

Thank you again and congratulation to the whole team, OMPL is a nice 
library and well documented.
Regards,
Yoann.






On 09/30/2016 06:40 PM, Mark Moll wrote:
> Hi Yoann,
>
> My answers are below inline.
>
> Mark
>
>
>
>> On Sep 28, 2016, at 7:23 AM, Yoann Solana <ys...@la... 
>> <mailto: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/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!.
>
>
>