Re: [ompl-users] PRM learning phase

[daniel c. <dan...@gm...>]

Hi Ioan,

I downloaded recent ompl version but prm code seems older (not by ryan).
Can you please send me corresponding prm files (source/header) or any link
pointing to source and header files? That would be a great help!!

Thank you,
Daniel

On Sat, Apr 21, 2012 at 2:10 AM, Ioan Sucan <is...@gm...> wrote:

> Hello Daniel,
>
> To keep things simple when using planners in an abstract way, we ask the
> user to only call the solve() function for a planner to solve a problem.
> For PRM itself, there are growRoadmap functions which allow you to grow a
> roadmap a priory. Hoever, calling those functions is optional because solve
> for PRM works as follows:
>
> - add input states to the roadmap
> - while input states are not connected, grow the roadmap.
> - when they are connected, stop growing the roadmap and return the
> solution.
>
> Just recently Ryan Luna added an improvement to the PRM code that allows
> it to run more efficiently, and I think allows for a cleaner
> implementation: the check for the roadmap being able to connect an input
> state to a goal state is done in a separate thread. Lines 399 - 402 in
> PRM.cpp (rev 1852) are responsible for growing the roadmap, from the solve
> function, while the checkForSolution() function runs in a separate thread.
>
> So the answer is that solve() improves the roadmap as needed, if it can't
> solve the problem when called. And this happens of course if the initial
> roadmap is empty.
>
> For the second part of your question, PlannerInputStates is a helper class
> that allows implementations of planners to be simpler. Namely,
> PlannerInputStates makes it trivial to retrieve only valid input states
> (start or goal), wait for goal samplers if they're produced in a separate
> thread (GoalLazySamples), things like this. One is not required to use this
> class, but without it, things tend to get complicated if you want to
> support all goal types.
> If you see parts  in the documentation that are not clear, please let me
> know and I will improve it.
>
> Ioan
>
>
>  On Sat, Apr 21, 2012 at 11:58 AM, daniel chan <dan...@gm...>wrote:
>
>>  Hello Ioan,
>>
>> I was looking into the PRM.cpp file and could not figure out where you
>> have written the routine for constructing the roadmap before calling
>> "solve" function (where you are adding start and goal states and doing
>> additional construction and expansion steps if solution is not found). Can
>> you please tell where in the PRM.cpp file you are building the roadmap
>> before calling solve function?
>>
>> What are valid input states (PlannerInputStates)? Are these refering to
>> start and goal states? Say if we have set only one start and one goal
>> states then pis->next() should provide only those start and goal state?
>> It seems to me there is no random-bounce walk for the start and goal
>> states, if it is not possible to connect (start/goal) to roadmap using
>> nearest neighbor concept?
>>
>> Daniel
>>
>>
>>
>> ------------------------------------------------------------------------------
>> For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>> _______________________________________________
>> ompl-users mailing list
>> omp...@li...
>> https://lists.sourceforge.net/lists/listinfo/ompl-users
>>
>>
>