## ompl-users — Users mailing list

You can subscribe to this list here.

 2010 2011 2012 2013 2014 2015 2016 2017 Jan Feb Mar Apr May Jun Jul Aug (1) Sep Oct Nov Dec Jan (4) Feb (6) Mar (16) Apr (9) May (6) Jun (2) Jul Aug (14) Sep (10) Oct (12) Nov (15) Dec (3) Jan (15) Feb (9) Mar (10) Apr (19) May (20) Jun (14) Jul (1) Aug (2) Sep Oct (3) Nov (1) Dec (2) Jan (13) Feb (8) Mar (11) Apr (20) May (11) Jun (11) Jul (12) Aug (3) Sep Oct (7) Nov (9) Dec (1) Jan (1) Feb (4) Mar (13) Apr (5) May (10) Jun (27) Jul (17) Aug Sep (8) Oct (12) Nov (19) Dec (31) Jan (21) Feb (11) Mar (15) Apr (1) May (15) Jun (11) Jul (23) Aug (6) Sep (28) Oct (17) Nov (18) Dec (1) Jan (14) Feb (42) Mar (20) Apr (10) May (11) Jun (3) Jul (9) Aug (6) Sep (6) Oct (8) Nov Dec (1) Jan (3) Feb (1) Mar (2) Apr (6) May (11) Jun (2) Jul Aug Sep Oct Nov Dec
S M T W T F S

1

2

3

4

5

6
(2)
7

8

9

10

11

12
(1)
13

14

15

16

17
(2)
18

19
(1)
20

21

22
(4)
23

24
(3)
25
(1)
26

27

28

29

30

31

Showing 14 results of 14

 Re: [ompl-users] Using different distance metric in state space From: Gustavo Goretkin - 2011-08-25 05:31:47 ```Thank you for the helpful examples! On Wed, Aug 24, 2011 at 9:43 AM, Mark Moll wrote: > Or you can do it in this slightly more involved way that does call the constructor with the list of sub-spaces directly: > > ------------------------- > from ompl import base as ob > > R0 = ob.RealVectorStateSpace(1) > R1 = ob.RealVectorStateSpace(1) > R01 = ob.vectorStateSpacePtr() > R01.extend([R0, R1]) > w = ob.vectorDouble() > w.extend([1, .5]) > C = ob.CompoundStateSpace(R01, w) > > s = ob.State(C) > print s > ------------------------- > > On Aug 24, 2011, at 8:27 AM, Mark Moll wrote: > >> You can do it this way: >> >> ------------------------- >> from ompl import base as ob >> >> R0 = ob.RealVectorStateSpace(1) >> R1 = ob.RealVectorStateSpace(1) >> C = ob.CompoundStateSpace() >> C.addSubSpace(R0, 1) >> C.addSubSpace(R1, .5) >> >> s = ob.State(C) >> print s >> ------------------------- >> >> On Aug 24, 2011, at 1:47 AM, Gustavo Goretkin wrote: >> >>> I liked the suggestion using the CompoundStateSpace. >>> >>> I am using the Python bindings but I haven't been able to create the >>> std::vector of components to pass to the CompoundStateSpace >>> constructor. I've seen this reference here [1] about collections and >>> boost.python, Py++ but I don't know how to create the std::vector< >>> StateSpacePtr > and std::vector< double > objects in the first place. >>> >>> >>> On Mon, Aug 22, 2011 at 3:38 PM, Mark Moll wrote: >>>> >>>> You can either create a CompoundStateSpace of RealVectorSpace with different weights for each sub-state space or subclass an existing state space as you suggested. >>>> >>>> On Aug 22, 2011, at 2:02 PM, Gustavo Goretkin wrote: >>>> >>>>> What's the proper way to define a new distance metric for a >>>>> StateSpace? For example, I'd like to use a Euclidean metric, but with >>>>> weights on each dimension, what could I do? >>>>> >>>>> I thought about subclassing RealVectorSpace, but I thought that there >>>>> might be away to set a pointer to a distance function (just as is done >>>>> for the propagate function in the control planners). >>>>> >>>>> Thanks, >>>>> Gustavo >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> uberSVN's rich system and user administration capabilities and model >>>>> configuration take the hassle out of deploying and managing Subversion and >>>>> the tools developers use with it. Learn more about uberSVN and get a free >>>>> download at:  http://p.sf.net/sfu/wandisco-dev2dev >>>>> _______________________________________________ >>>>> ompl-users mailing list >>>>> ompl-users@... >>>>> https://lists.sourceforge.net/lists/listinfo/ompl-users >>>>> >>>> >>>> -- >>>> Mark Moll >>>> >>>> >>>> >>> >> >> -- >> Mark Moll >> >> >> > > -- > Mark Moll > > > > ```
 Re: [ompl-users] Using different distance metric in state space From: Mark Moll - 2011-08-24 13:44:07 ```Or you can do it in this slightly more involved way that does call the constructor with the list of sub-spaces directly: ------------------------- from ompl import base as ob R0 = ob.RealVectorStateSpace(1) R1 = ob.RealVectorStateSpace(1) R01 = ob.vectorStateSpacePtr() R01.extend([R0, R1]) w = ob.vectorDouble() w.extend([1, .5]) C = ob.CompoundStateSpace(R01, w) s = ob.State(C) print s ------------------------- On Aug 24, 2011, at 8:27 AM, Mark Moll wrote: > You can do it this way: > > ------------------------- > from ompl import base as ob > > R0 = ob.RealVectorStateSpace(1) > R1 = ob.RealVectorStateSpace(1) > C = ob.CompoundStateSpace() > C.addSubSpace(R0, 1) > C.addSubSpace(R1, .5) > > s = ob.State(C) > print s > ------------------------- > > On Aug 24, 2011, at 1:47 AM, Gustavo Goretkin wrote: > >> I liked the suggestion using the CompoundStateSpace. >> >> I am using the Python bindings but I haven't been able to create the >> std::vector of components to pass to the CompoundStateSpace >> constructor. I've seen this reference here [1] about collections and >> boost.python, Py++ but I don't know how to create the std::vector< >> StateSpacePtr > and std::vector< double > objects in the first place. >> >> >> On Mon, Aug 22, 2011 at 3:38 PM, Mark Moll wrote: >>> >>> You can either create a CompoundStateSpace of RealVectorSpace with different weights for each sub-state space or subclass an existing state space as you suggested. >>> >>> On Aug 22, 2011, at 2:02 PM, Gustavo Goretkin wrote: >>> >>>> What's the proper way to define a new distance metric for a >>>> StateSpace? For example, I'd like to use a Euclidean metric, but with >>>> weights on each dimension, what could I do? >>>> >>>> I thought about subclassing RealVectorSpace, but I thought that there >>>> might be away to set a pointer to a distance function (just as is done >>>> for the propagate function in the control planners). >>>> >>>> Thanks, >>>> Gustavo >>>> >>>> ------------------------------------------------------------------------------ >>>> uberSVN's rich system and user administration capabilities and model >>>> configuration take the hassle out of deploying and managing Subversion and >>>> the tools developers use with it. Learn more about uberSVN and get a free >>>> download at: http://p.sf.net/sfu/wandisco-dev2dev >>>> _______________________________________________ >>>> ompl-users mailing list >>>> ompl-users@... >>>> https://lists.sourceforge.net/lists/listinfo/ompl-users >>>> >>> >>> -- >>> Mark Moll >>> >>> >>> >> > > -- > Mark Moll > > > -- Mark Moll ```
 Re: [ompl-users] Using different distance metric in state space From: Mark Moll - 2011-08-24 13:27:30 ```You can do it this way: ------------------------- from ompl import base as ob R0 = ob.RealVectorStateSpace(1) R1 = ob.RealVectorStateSpace(1) C = ob.CompoundStateSpace() C.addSubSpace(R0, 1) C.addSubSpace(R1, .5) s = ob.State(C) print s ------------------------- On Aug 24, 2011, at 1:47 AM, Gustavo Goretkin wrote: > I liked the suggestion using the CompoundStateSpace. > > I am using the Python bindings but I haven't been able to create the > std::vector of components to pass to the CompoundStateSpace > constructor. I've seen this reference here [1] about collections and > boost.python, Py++ but I don't know how to create the std::vector< > StateSpacePtr > and std::vector< double > objects in the first place. > > > On Mon, Aug 22, 2011 at 3:38 PM, Mark Moll wrote: >> >> You can either create a CompoundStateSpace of RealVectorSpace with different weights for each sub-state space or subclass an existing state space as you suggested. >> >> On Aug 22, 2011, at 2:02 PM, Gustavo Goretkin wrote: >> >>> What's the proper way to define a new distance metric for a >>> StateSpace? For example, I'd like to use a Euclidean metric, but with >>> weights on each dimension, what could I do? >>> >>> I thought about subclassing RealVectorSpace, but I thought that there >>> might be away to set a pointer to a distance function (just as is done >>> for the propagate function in the control planners). >>> >>> Thanks, >>> Gustavo >>> >>> ------------------------------------------------------------------------------ >>> uberSVN's rich system and user administration capabilities and model >>> configuration take the hassle out of deploying and managing Subversion and >>> the tools developers use with it. Learn more about uberSVN and get a free >>> download at: http://p.sf.net/sfu/wandisco-dev2dev >>> _______________________________________________ >>> ompl-users mailing list >>> ompl-users@... >>> https://lists.sourceforge.net/lists/listinfo/ompl-users >>> >> >> -- >> Mark Moll >> >> >> > -- Mark Moll ```
 Re: [ompl-users] Using different distance metric in state space From: Gustavo Goretkin - 2011-08-24 06:47:35 ```I liked the suggestion using the CompoundStateSpace. I am using the Python bindings but I haven't been able to create the std::vector of components to pass to the CompoundStateSpace constructor. I've seen this reference here [1] about collections and boost.python, Py++ but I don't know how to create the std::vector< StateSpacePtr > and std::vector< double > objects in the first place. On Mon, Aug 22, 2011 at 3:38 PM, Mark Moll wrote: > > You can either create a CompoundStateSpace of RealVectorSpace with different weights for each sub-state space or subclass an existing state space as you suggested. > > On Aug 22, 2011, at 2:02 PM, Gustavo Goretkin wrote: > > > What's the proper way to define a new distance metric for a > > StateSpace? For example, I'd like to use a Euclidean metric, but with > > weights on each dimension, what could I do? > > > > I thought about subclassing RealVectorSpace, but I thought that there > > might be away to set a pointer to a distance function (just as is done > > for the propagate function in the control planners). > > > > Thanks, > > Gustavo > > > > ------------------------------------------------------------------------------ > > uberSVN's rich system and user administration capabilities and model > > configuration take the hassle out of deploying and managing Subversion and > > the tools developers use with it. Learn more about uberSVN and get a free > > download at:  http://p.sf.net/sfu/wandisco-dev2dev > > _______________________________________________ > > ompl-users mailing list > > ompl-users@... > > https://lists.sourceforge.net/lists/listinfo/ompl-users > > > > -- > Mark Moll > > > ```
 Re: [ompl-users] Using different distance metric in state space From: Mark Moll - 2011-08-22 19:38:36 ```You can either create a CompoundStateSpace of RealVectorSpace with different weights for each sub-state space or subclass an existing state space as you suggested. On Aug 22, 2011, at 2:02 PM, Gustavo Goretkin wrote: > What's the proper way to define a new distance metric for a > StateSpace? For example, I'd like to use a Euclidean metric, but with > weights on each dimension, what could I do? > > I thought about subclassing RealVectorSpace, but I thought that there > might be away to set a pointer to a distance function (just as is done > for the propagate function in the control planners). > > Thanks, > Gustavo > > ------------------------------------------------------------------------------ > uberSVN's rich system and user administration capabilities and model > configuration take the hassle out of deploying and managing Subversion and > the tools developers use with it. Learn more about uberSVN and get a free > download at: http://p.sf.net/sfu/wandisco-dev2dev > _______________________________________________ > ompl-users mailing list > ompl-users@... > https://lists.sourceforge.net/lists/listinfo/ompl-users > -- Mark Moll ```
 [ompl-users] Using different distance metric in state space From: Gustavo Goretkin - 2011-08-22 19:02:28 ```What's the proper way to define a new distance metric for a StateSpace? For example, I'd like to use a Euclidean metric, but with weights on each dimension, what could I do? I thought about subclassing RealVectorSpace, but I thought that there might be away to set a pointer to a distance function (just as is done for the propagate function in the control planners). Thanks, Gustavo ```
 Re: [ompl-users] Finite Control Space From: Mark Moll - 2011-08-22 18:58:30 ```Gustavo, Take a look at DiscreteStateSpace. This implements something analogous for state spaces. Like you suggested, the types of “meshes” you mention can then easily be constructed using the CompoundControl class. For state spaces there are handy operators so you can construct state space meshes like so: ompl::base::StateSpacePtr X = ompl::base::StateSpacePtr(new ompl::base::DiscreteStateSpace()); ompl::base::StateSpacePtr Y = ompl::base::StateSpacePtr(new ompl::base::DiscreteStateSpace()); ompl::base::StateSpacePtr XYGrid = X+Y; This does not exist yet for ControlSpaces, because we only have one concrete implementation of a control space (RealVectorControlSpace). On Aug 22, 2011, at 1:16 PM, Gustavo Goretkin wrote: > Ioan, > > Thanks for the encouragement! I have not yet implemented this, but I > would like to start on it soon. I am considering the following > approach. > > Make a RealVectorControlSpaceDiscrete (or better name) that is > constructed with a finite list of vector values. For example a > discrete control space in 2 dimensions where only one dimension should > be non-zero for a given control could be initialized with a list of > vectors like [(0,1) ; (0,-1); (0,0); (1,0); (-1,0)] > > If we want a "mesh" control space, where each dimension can be sampled > independently, it would probably better to make several > RealVectorControlSpaceDiscrete spaces (one for each dimension) and > combine them in a CompoundControl. > > Thanks, > Gustavo > > On Wed, Aug 17, 2011 at 12:25 PM, Ioan Alexandru Sucan wrote: >> Gustavo, >> >> Your intuition is correct. If you simply change the sampler for a >> RealVectorControlSpace, things will work as you expect. >> >> However, a representation of a discrete set of controls >> (DiscreteControlSpace) could be added to OMPL (I am quite inclined to do >> so). >> Please let me know if you would find that useful. Or, if you have it >> implemented (or plan to implement it), we would welcome your contribution. >> >> Thanks for pointing this out! >> >> Ioan >> >> On Wed, Aug 17, 2011 at 4:28 PM, Gustavo Goretkin >> wrote: >>> >>> Are there any facilities in OMPL to describe a finite control space as >>> opposed to a continuous control space? For the kinodynamic motion planners, >>> is the only step that would need to be changed the control sampling step? >>> >>> Thanks, >>> Gustavo >>> >>> >>> ------------------------------------------------------------------------------ >>> Get a FREE DOWNLOAD! and learn more about uberSVN rich system, >>> user administration capabilities and model configuration. Take >>> the hassle out of deploying and managing Subversion and the >>> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 >>> _______________________________________________ >>> ompl-users mailing list >>> ompl-users@... >>> https://lists.sourceforge.net/lists/listinfo/ompl-users >>> >> >> > > ------------------------------------------------------------------------------ > uberSVN's rich system and user administration capabilities and model > configuration take the hassle out of deploying and managing Subversion and > the tools developers use with it. Learn more about uberSVN and get a free > download at: http://p.sf.net/sfu/wandisco-dev2dev > _______________________________________________ > ompl-users mailing list > ompl-users@... > https://lists.sourceforge.net/lists/listinfo/ompl-users > -- Mark Moll ```
 Re: [ompl-users] Finite Control Space From: Gustavo Goretkin - 2011-08-22 18:17:04 ```Ioan, Thanks for the encouragement! I have not yet implemented this, but I would like to start on it soon. I am considering the following approach. Make a RealVectorControlSpaceDiscrete (or better name) that is constructed with a finite list of vector values. For example a discrete control space in 2 dimensions where only one dimension should be non-zero for a given control could be initialized with a list of vectors like [(0,1) ; (0,-1); (0,0); (1,0); (-1,0)] If we want a "mesh" control space, where each dimension can be sampled independently, it would probably better to make several RealVectorControlSpaceDiscrete spaces (one for each dimension) and combine them in a CompoundControl. Thanks, Gustavo On Wed, Aug 17, 2011 at 12:25 PM, Ioan Alexandru Sucan wrote: > Gustavo, > > Your intuition is correct. If you simply change the sampler for a > RealVectorControlSpace, things will work as you expect. > > However, a  representation of a discrete set of controls > (DiscreteControlSpace) could be added to OMPL (I am quite inclined to do > so). > Please let me know if you would find that useful. Or, if you have it > implemented (or plan to implement it), we would welcome your contribution. > > Thanks for pointing this out! > > Ioan > > On Wed, Aug 17, 2011 at 4:28 PM, Gustavo Goretkin > wrote: >> >> Are there any facilities in OMPL to describe a finite control space as >> opposed to a continuous control space? For the kinodynamic motion planners, >> is the only step that would need to be changed the control sampling step? >> >> Thanks, >> Gustavo >> >> >> ------------------------------------------------------------------------------ >> Get a FREE DOWNLOAD! and learn more about uberSVN rich system, >> user administration capabilities and model configuration. Take >> the hassle out of deploying and managing Subversion and the >> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 >> _______________________________________________ >> ompl-users mailing list >> ompl-users@... >> https://lists.sourceforge.net/lists/listinfo/ompl-users >> > > ```
 [ompl-users] ompl 0.9.4 released From: Mark Moll - 2011-08-19 03:10:57 ```We are happy to announce a new release of OMPL, version 0.9.4. This release includes the following changes: • Renamed StateManifold to StateSpace and ControlManifold to ControlSpace • Added RRTstar contribution • Added GNAT nearest neighbors datastructure • Added representation of a discrete state space (DiscreteStateSpace) • Added representation of probability density functions (PDF) • Replaced the implementation of BasicPRM with PRM. Thanks to James Marble, the new implementation uses BGL. • Moved state propagation functionality from ControlSpace to a separate StatePropagator class • Added SimpleSetup-derived classes to the OMPL.app library for several control-based systems: kinematic car, Reeds-Shepp car, Dubins car, dynamic car, blimp, and quadrotor. Made them accessible through the OMPL.app GUI. • Added isStraightLinePathValid() to PlannerDefinition • Using boost ublas for real vector projections • Add sanity checks for state spaces • Benchmarked planners are now run in a separate thread (and termination conditions are evaluated separately, to detect crashes) • Added getType() for Goal and replaced getType() for planners by getSpecs() • Generalized planner termination conditions. The user can now call terminate() at any time to signal a planner it should stop its computation • Improvements to control::KPIECE1, so that it considers goal biasing more appropriately • Move code for extracting machine properties from util/ to benchmark/ • Documentation fixes Point your browser to http://ompl.kavrakilab.org/download.html to download the latest version. -- Mark Moll ```
 Re: [ompl-users] Finite Control Space From: Ioan Alexandru Sucan - 2011-08-17 16:26:05 Attachments: Message as HTML ```Gustavo, Your intuition is correct. If you simply change the sampler for a RealVectorControlSpace, things will work as you expect. However, a representation of a discrete set of controls (DiscreteControlSpace) could be added to OMPL (I am quite inclined to do so). Please let me know if you would find that useful. Or, if you have it implemented (or plan to implement it), we would welcome your contribution. Thanks for pointing this out! Ioan On Wed, Aug 17, 2011 at 4:28 PM, Gustavo Goretkin < gustavo.goretkin@...> wrote: > Are there any facilities in OMPL to describe a finite control space as > opposed to a continuous control space? For the kinodynamic motion planners, > is the only step that would need to be changed the control sampling step? > > Thanks, > Gustavo > > > ------------------------------------------------------------------------------ > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, > user administration capabilities and model configuration. Take > the hassle out of deploying and managing Subversion and the > tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 > _______________________________________________ > ompl-users mailing list > ompl-users@... > https://lists.sourceforge.net/lists/listinfo/ompl-users > > ```
 [ompl-users] Finite Control Space From: Gustavo Goretkin - 2011-08-17 15:29:26 Attachments: Message as HTML ```Are there any facilities in OMPL to describe a finite control space as opposed to a continuous control space? For the kinodynamic motion planners, is the only step that would need to be changed the control sampling step? Thanks, Gustavo ```
 [ompl-users] Python bindings control object From: Gustavo Goretkin - 2011-08-12 15:37:16 Attachments: Message as HTML ```I am using the RigidBodyPlanningWithControls.py demo and I'd like to access the controls. I can already access the geometric path that the controls correspond to. As far as I can tell, ss.getSolutionPath().controls returns a vector of ControlType. It's promising that len(ss.getSolutionPath().controls) = len(ss.getSolutionPath().states) - 1 So I can index into the control vector like: control = ss.getSolutionPath().controls[i] It looks like the index operator is too defined for ControlType. The first indices (for this demo) seem to correspond with the elements of the control vector. But in this demo I can also do control[2] and control[200]. All of these indices that I expect to be out-of-bounds return values circa 1e-316 (close to float minimum). ```
 Re: [ompl-users] Access PathGeometric in Python From: Mark Moll - 2011-08-06 20:04:25 ```ScopedState objects can be created like so: space = ob.RealVectorStateSpace(3) ... ss = simpleSetup(space) ... if ss.solve(10): # PathGeometric object path = ss.getSolutionPath() # python list of lists of doubles n = len(path.states) path = [[ob.State(space, path.states[i])[j] for j in range(3)] for i in range(n)] print path The "ob.State(space, path.states[i])” part creates the ScopedState object. You can look at the ompl_app.py code to see how you’d convert SE(2) and SE(3) states to transformation matrices. On Aug 6, 2011, at 4:35 AM, Gustavo Goretkin wrote: > I'd like to access a PathGeometric object as a Numpy array. I can loop through PathGeometric.states, which is a collection of RealVectorStateInternal (or the appropriate state depending on the manifold) but as [1] suggests, this is not the best way. How can I get the ScopedState objects? > > Thanks, > Gustavo > > [1] http://ompl-beta.kavrakilab.org/core/python.html#cpp_py_diffs -- Mark Moll ```
 [ompl-users] Access PathGeometric in Python From: Gustavo Goretkin - 2011-08-06 09:35:28 Attachments: Message as HTML ```I'd like to access a PathGeometric object as a Numpy array. I can loop through PathGeometric.states, which is a collection of RealVectorStateInternal (or the appropriate state depending on the manifold) but as [1] suggests, this is not the best way. How can I get the ScopedState objects? Thanks, Gustavo [1] http://ompl-beta.kavrakilab.org/core/python.html#cpp_py_diffs ```

Showing 14 results of 14