Add hints about OMPL roadmap caching (#486)

Author: AndyZe

doc/examples/ompl_interface/ompl_interface_tutorial.rst

@@ -165,4 +165,6 @@ By default the planning algorithms start from scratch for each motion planning r
 
 The first planner configuration, ``PersistentLazyPRMstar``, will use LazyPRM* to keep growing a roadmap of asymptotically optimal paths between sampled robot configurations with each motion planning request. Upon destruction of the planner instance, it will save the roadmap to disk. The ``PersistentLazyPRM`` configuration is similar, except it will *load* a roadmap from disk but not *save* it upon destruction. The ``SemiPersistent`` planner configurations do not load/save roadmaps, but do keep extending a roadmap with each motion planning request (rather than the default behavior of clearing it before planning). The four planners that support the persistent planning features are: PRM, PRM*, LazyPRM, and LazyPRM*. The critical difference between them is that the lazy variants will re-validate the validity of nodes and edges as needed when searching the roadmap for a valid path. The non-lazy variants will not check if the roadmap is still valid for the current environment. In other words, use the non-lazy variants for static environments, the lazy variants for environments with small changes, and a non-persistent planner if the environment can change significantly.
 
+It makes sense to use ``PersistentLazyPRMstar`` or ``PersistentPRMstar`` to create and store the roadmap initially since they are asymptotically optimal planners. After a roadmap is available, ``PersistentLazyPRM`` or ``PersistentPRM`` are often used for future planning attempts. They usually plan faster than the ``star`` variants while starting from the cached roadmap means the plan remains close to optimal. But, this order is not mandatory.
+
 *Note that saving and loading roadmaps is only available in OMPL 1.5.0 and newer.*