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

[Dave C. <Dav...@Co...>]

Thanks Mark for your answers, sorry for being late to the discussion. I
wanted to add some thoughts:

> 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?

In my current implementation, no - but you could add this feature. Since
your start and goal states are the same, should I assume you are referring
to changing obstacle environments? I think one key detail you are missing
is that even recalled paths are run through a smoother which, in OMPL's
case has a random aspect to it, and this smoother will have varying
solution paths given changing obstacle environments. This smoothed path is
then re-inserted back into the experience database and will often
improve/enrich the future solution quality.

> The database is *guaranteed* not to grow indefinitely.

This is true in theory, but I've found implementation issues in how SPARS's
smooths and inserts quality paths around corners, such that in my testing
it will continue to slowly grow indefinitely after hours of running on the
simplest 2D toy problems. I've had some luck working around this through
using variable clearance around obstacles.

> Is it possible to have more documentation about the implementation in
Moveit?

The setup I used was complicated and never merged into the main MoveIt!
codebase - it exists somewhere in the commit history of my forks. I did
create a PR for the key feature necessary to use experience planning in
MoveIt! - the ability to re-use a planning context such that you don't have
to load from file the experience database every problem. But it was never
merged in due to a dormant period in MoveIt!: https://github.com/
ros-planning/moveit_ros/pull/477

- davetcoleman

On Mon, Oct 3, 2016 at 9:13 PM, Mark Moll <mm...@ri...> wrote:

> Hi Yoann,
>
> You can set the "repair” planner
> <http://ompl.kavrakilab.org/classompl_1_1tools_1_1Thunder.html#ae2206a7c1f4a324519d443ce1acad468> in
> Thunder to RRT* or some other optimizing planner. By default RRT* will
> always use all the time you give it to compute a more optimal solution, but
> you can change this by specifying a optimality threshold
> <http://ompl.kavrakilab.org/classompl_1_1base_1_1OptimizationObjective.html#a1f133b98a94cb5b20c4b1a3a998aa7e9> for
> your optimization objective.
>
> A completely wild idea would be to use CForest
> <http://ompl.kavrakilab.org/classompl_1_1geometric_1_1CForest.html> with
> Thunder as one of your planners and RRT* as another one of your planners
> (or perhaps use a few RRT* instance). If you try that and it works, let me
> know :-).
>
> Mark
>
>
>
>
> On Oct 3, 2016, at 1:55 AM, Yoann Solana <ys...@la...> wrote:
>
> 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...> 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/omp
> l/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!.
>
>
>
>
>
>