Re: [ompl-users] Implementing ControlSampler::sampleTo()

[Simon C. <Simon.Chamberland@USherbrooke.ca>]

Thanks for your quick input!

I do think it makes sense to associate the ControlSampler to the
ControlSpace; on the other hand, the StatePropagator is associated to
the full SpaceInformation but seems to require only the ControlSpace to
operate. I don't have enough knowledge on the matter to determine
whether the design is appropriate.

I believe the "information about the model" you were talking about in
the ODEControlSpace is found in the ODESimpleSetup/ODEEnvironment
classes. This seems correct, however in my case additional classes are
not necessary.

I think I'll simply keep the step size in the ControlSpace as well, so
that the ControlSampler can ask for it when necessary. The problem with
duplicating data, obviously, is that I need to make sure
SpaceInformation::stepSize and ControlSpace::stepSize stay synchronized.

Also, just wanted to add that developing an open-source motion planning
library is truly a great initiative and will help research in the
domain! I worked a little with OOPSMP a few years ago and I see it
inspired OMPL design.

Simon

On Mon, 2011-11-14 at 19:03 +0000, Ioan Sucan wrote:
> Hello Simon,
> 
> This is a very interesting question.
> I don't think you missed anything from the API. Essentially what it
> comes down to is whether samples have an instance of the
> SpaceInformation internally or an instance of the space they
> correspond to. Since we are implementing samplers for that particular
> space, it seems to me the better approach is to maintain pointers to
> spaces only.
> However, I do see that it is not as convenient as we'd want it to be
> in some cases.
> 
> The approach that Mark mentioned is almost correct, but does not work
> because the allocControlSampler() function he suggests re-implementing
> is not virtual. That is done on purpose, so that you always get the
> same result as calling allocControlSamper() directly from the
> ControlSpace.
> 
> Now, back to your problem. What I usually do is that I have some class
> that represents information about the model I am propagating motions
> for / sampling controls for. You can take a look at how
> ODEControlSpace is implemented (in extensions)
> 
> Then, I pass a pointer to this class to the ControlSampler,
> StateSpace, whoever else needs it. I configure the SpaceInformation
> from this class, and in the sampler I read the propagation size as
> needed from that class. Does this make sense?
> 
> Ioan
> 
> 
> On Mon, Nov 14, 2011 at 6:52 PM, Mark Moll <mm...@ri...> wrote:
>         
>         On Nov 14, 2011, at 11:48 AM, Simon Chamberland wrote:
>         > I’m implementing a ControlSampler on top of my own custom
>         StateSpace/ControlSpace/StatePropagator classes.
>         >
>         > Certain “sampleTo()” overloads require returning the number
>         of steps the control must be applied for. In order to
>         calculate the number of steps one needs the propagation step
>         size, which is set in the SpaceInformation instance. However,
>         the only parameter supplied to the ControlSampler is the
>         ControlSpace, from which it is not possible to retrieve the
>         SpaceInformation instance.
>         >
>         > I would simply pass the step size as an additional parameter
>         to my ControlSampler, but unfortunately said ControlSampler is
>         instantiated by the ControlSpace.
>         >
>         > Am I missing something, or is there a way to get around
>         that?
>         
>         
>         
>         You could pass the propagation step size, as obtained from the
>         SpaceInformation instance, to the constructor of your
>         ControlSampler-derived class. You’d then create a
>         control::SpaceInformation-derived class that overrides
>         allocControlSampler. That seems a bit involved. Can anyone
>         think of a simpler / cleaner solution.
>         
>         --
>         Mark Moll
>         
>         
>         
>         
>         ------------------------------------------------------------------------------
>         RSA(R) Conference 2012
>         Save $700 by Nov 18
>         Register now
>         http://p.sf.net/sfu/rsa-sfdev2dev1
>         _______________________________________________
>         ompl-users mailing list
>         omp...@li...
>         https://lists.sourceforge.net/lists/listinfo/ompl-users
>