[ompl-users] Fwd: Re: Re: Planners return colliding paths

[<is...@gm...>]

addin CC:


> On Mar 24, 2011 10:36am, Boris Lau la...@in...> wrote:
> > Hi Ioan,
> >
> >
> >
> > thank you very much for your quick reply.
> >
> >
> >
> > My understanding of the resolution is this:
> >
> > I can simply choose to map the grid space coordinates to the continuous  
> space 1:1. Therefore, I use 0 and the width/height (whatever is bigger)  
> of the map as manifold bounds. Then I need a maximum stepsize of 1 cell,  
> therefore 1/extent.
> >
> > And indeed, when I print out which cells are checked for collisions,  
> they are indeed either adjacent, or the algorithm is jumping somewhere  
> else.
> >
> >
> Your understanding is correct. The jumping around it the problem, but I  
> guess we have not yet figured it out.

> > Here are pictures of RRT and KPIECE1 paths. Each step in the path is  
> one picture, frame by frame:
> > http://www.informatik.uni-freiburg.de/~lau/generated_paths.zip
> >
> Thank you.
> Can we try a bit more debugging?
> When you get the solution path, there are some checks you can run.
> For example:

> ss.getSolutionPath().check() should complain if the path is invalid. Can  
> you tell me if this reports true or false? (for RRT & KPIECE)
> In addition to this, before generating your frame-by-frame images, you  
> can do
> ss.getSolutionPath().interpolate() so that states are created along the  
> path at the collision checking resolution. This would allow us to see  
> (approximately) which states the planner checks for collisions.
> Could you generate those pictures as well?

> The RRT-type planners are slightly different from the EST & KPIECE type  
> planners, but they should provide at least comparable performance (I  
> suspect better) for the problem you are solving.

> >
> >
> > As you can see, the RRT returns a very sparse but valid path, and the  
> KPIECE1 does something weird. The only thing I change is using either
> >
> > ss.setPlanner((ompl::base::PlannerPtr)(new og::RRT(si)));
> >
> > or ss.setPlanner((ompl::base::PlannerPtr)(new og::KPIECE1(si)));
> >
> >
> This is correct (I still prefer the shared pointer constructor rather  
> than casting, but if valgrind is happy, I am happy :) )

> >
> > The rest is as in the simple setup example. Do I need to setup a  
> projection thing myself?
> >
> You can, but since you are using a default manifold, you don't need to.  
> x, y is the default projection, so dimension 2 is correct (sorry about  
> that)
> You should however set the cell sizes, as that can influence the runtime  
> of the planner significantly. I would try something like with / 20 ,  
> height/20 for the sizes.
> (which is the default, if you are using 0.9.2; we're trying to make this  
> automatic for 0.9.3)

> >
> > And by the way, my colleague Christoph Sprunk says hi, you've met at  
> the BRICS labor camp.

> I remember Christoph, say hello to him as well ;)
> Is he going to the next one?

> Ioan

> >
> >
> >
> > Best, Boris
> >
> >
> >
> > --
> >
> > Boris Lau
> >
> >
> >
> > Albert-Ludwigs-University Freiburg
> >
> > Institute of Computer Science, Autonomous Intelligent Systems Group
> >
> > Georges-Koehler-Allee 079, D-79110 Freiburg, Germany
> >
> >
> >
> > Building 079, Room 1005
> >
> > Phone: +49 761 203-8012 | Mobile: +49 174 9436758
> >
> > http://www.informatik.uni-freiburg.de/~lau
> >
> >