From: Simon C. <Simon.Chamberland@USherbrooke.ca> - 2011-11-15 15:02:11
|
Hey Ioan, That sounds like a better solution! I believe I have an older version as I dont see any function in StateSpace to set a custom StateSamplerAllocator. So yes please go ahead with the modification, and Ill download the latest version from the repository. Thanks! Simon _____ De : Ioan Sucan [mailto:is...@gm...] Envoyé : November 14, 2011 6:16 PM À : Simon Chamberland Cc : Mark Moll; omp...@li... Objet : Re: [ompl-users] Implementing ControlSampler::sampleTo() Simon, I just figured out a nicer way for you to solve your problem, but it would require you using the repository version of OMPL and waiting for a commit from me. If you look at the StateSpace & StateSampler classes, they are similar in structure to ControlSpace & ControlSampler. The StateSpace is a little more used and has more functionality. Included in this functionality is the option to set a different StateSamplerAllocator. This has not been added yet to the ControlSampler. Essentially, what you can do is define your own ControlSampler that takes a SpaceInformation instance as argument to the constructor. Then define a function like: ompl::control::ControlSamplerPtr allocMyControlSampler(ompl::control::SpaceInformation *si, ompl::control::ControlSpace *cspace) { // assert si->getControlSpace().get() == cspace return ControlSamplerPtr ( new MyControlSampler(si) ) ; } and then do something like: control_space->setControlSamplerAllocator(boost::function(&allocMyControlSam pler, space_information_to_use, _1)); and then.. there is no duplication of information. If you like this solution better, I'll push the change to the control space as well. Ioan 2011/11/14 Simon Chamberland <Sim...@us...> 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: > > Im 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. Youd 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 > |