ompl-users — Users mailing list

Re: [ompl-users] OMPL.app

[Mark M. <mm...@ri...>]

On Jan 16, 2012, at 12:11 PM, Alvaro Retortillo wrote:
> What happened with OMPL.app?


There are two different distributions of OMPL: one with just the core library and one with the OMPL.app extras. Make sure you download the right version.

-- 
Mark Moll

[ompl-users] Error update_bindings

[Alvaro R. <ret...@us...>]

Hi all,

I am trying to install OMPL in ubuntu 10.04. I have installed all packages
required.

I get this error at make update_bindings:

[ 36%] Creating C++ code for Python module geometric (see
pyplusplus_geometric.log)
make[3]: *** [ompl/py-bindings/CMakeFiles/update_geometric_bindings] Error 1
make[2]: ***
[ompl/py-bindings/CMakeFiles/update_geometric_bindings.dir/all] Error 2
make[1]: *** [ompl/py-bindings/CMakeFiles/update_bindings.dir/rule] Error 2
make: *** [update_bindings] Error 2

Contents of pyplusplus_geometric.log

INFO: Replacing member function
::ompl::geometric::SimpleSetup::setStateValidityChecker
Traceback (most recent call last):
  File
"/root/ompl_install/omplapp-0.9.5-Source/ompl/py-bindings/generate_bindings.py",
line 516, in <module>
    globals()['ompl_'+module+'_generator_t']()
  File
"/root/ompl_install/omplapp-0.9.5-Source/ompl/py-bindings/generate_bindings.py",
line 445, in __init__
    code_generator_t.__init__(self, 'geometric', ['bindings/base'],
replacement)
  File
"/root/ompl_install/omplapp-0.9.5-Source/ompl/py-bindings/ompl/bindings_generator.py",
line 125, in __init__
    self.filter_declarations()
  File
"/root/ompl_install/omplapp-0.9.5-Source/ompl/py-bindings/generate_bindings.py",
line 496, in filter_declarations
    self.ompl_ns.class_('NearestNeighbors<unsigned long>').include()
  File
"/usr/local/lib/python2.7/site-packages/pygccxml/declarations/scopedef.py",
line 409, in class_
    , recursive=recursive)
  File
"/usr/local/lib/python2.7/site-packages/pygccxml/declarations/scopedef.py",
line 357, in _find_single
    found = matcher_module.matcher.get_single( matcher, decls, False )
  File
"/usr/local/lib/python2.7/site-packages/pygccxml/declarations/matcher.py",
line 82, in get_single
    raise matcher.declaration_not_found_t( decl_matcher )
pygccxml.declarations.matcher.declaration_not_found_t: Unable to find
declaration.  matcher: [(decl type==class_t) and (name==NearestNeighbors<
unsigned long >)]


I am lost. Cannot see through.  Thanks!!

[ompl-users] OMPL.app

[Alvaro R. <ret...@us...>]

Hi all,

What happened with OMPL.app?

[ompl-users] OMPL API Updates

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

Dear users,

Some of you have been using advanced features of control sampling. If you
have written a planner that uses control sampling or your own control
sampler / control space, please read on.

We realized that the sampleTo() functions which were recently added to the
ControlSampler often require additional information about the planning
context, in addition to the ControlSpace itself. In essence, it could be
argued that previous ControlSampler functions ( sample() and sampleNext() )
should have sufficient information for sampling given the ControlSpace.
However, the sampleTo() functions include a notion of direction, which
implicitly requires propagation. But the propagation routines are available
as part of the SpaceInformation, not in the ControlSpace.
For this reason, we split the ControlSampler into two concepts:
- ControlSampler ( same as before, but without the sampleTo() functions )
- DirectedControlSampler (this is a new concept, which includes the
sampleTo() functions, and its constructor takes a SpaceInformation* as
argument).

The control::SpaceInformation is aware of this DirectedControlSampler and
will allocate a default implementation if needed.
If you have any questions / suggestions / concerns, please reply to this
message.

Best wishes,
Ioan

Re: [ompl-users] Can I get the roadmap from the planner say PRM

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

Hello Vinay,

I am sorry  for this inconvenience, but the version for ROS electric is
changed only for bugfixes. We are about to release ROS fuerte, which will
include all the latest bells and whistles. There are few other API changes
that have occurred for OMPL and we don't want to change the software in
electric too much. Can you install the OMPL package by itself? There is a
ROS package in the svn repo shown here:
http://ompl.kavrakilab.org/core/download.html

Ioan

On Mon, Dec 19, 2011 at 10:50 AM, Vinay K <vin...@gm...> wrote:

> Hi Ioan,
>
> After updating my ros-electric, still I am getting constructSolution()
> function without being "virtual member". I separately downloaded ompl
> (without ros) and noticed that you have updated the PRM planner of ompl by
> changing the search algorithm but the changes are not reflected if I
> install ompl within ros (by installing arm navigation stack). As you said
> you 'll make this function virtual but somehow it was not done.
>
> Thanks,
> Vinay
>
>
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live!  Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> ompl-users mailing list
> omp...@li...
> https://lists.sourceforge.net/lists/listinfo/ompl-users
>
>

[ompl-users] Can I get the roadmap from the planner say PRM

[Vinay K <vin...@gm...>]

Hi Ioan,

After updating my ros-electric, still I am getting constructSolution()
function without being "virtual member". I separately downloaded ompl
(without ros) and noticed that you have updated the PRM planner of ompl by
changing the search algorithm but the changes are not reflected if I
install ompl within ros (by installing arm navigation stack). As you said
you 'll make this function virtual but somehow it was not done.

Thanks,
Vinay

Re: [ompl-users] ompl-devel post from peter.gschirr@gmail.com requires approval

[Mark M. <mm...@ri...>]

Peter,

This probably means that the python bindings did not get generated. Can you type “make update_bindings && make” in your build directory?


> From: Peter Gschirr <pet...@gm...>
> To: omp...@li...
> Date: Fri, 25 Nov 2011 14:50:52 +0000
> Subject: Problem with OMPL-GUI: ImportError: No module named _util
> Dear OMPL-developers,
> 
> I installed omplapp-0.9.5 on Ubuntu 11.10 and got the following error when I tried to start the GUI:
> 
> Traceback (most recent call last):
>   File "./ompl_app.py", line 37, in <module>
>     from ompl.util import OutputHandler, useOutputHandler
>   File "/home/ubuntu/Desktop/omplapp-0.9.5-Source/ompl/py-bindings/ompl/util/__init__.py", line 4, in <module>
>     from _util import *
> ImportError: No module named _util
> 
> All necessary packages that are mentioned in your help file are installed and the make also did not report any problems. 
> I tried it with the 32bit as well as with the 64bit version of Ubuntu, but no luck. It would be great if you could send me a solution to this problem, since I would like to show your tool in a presentation.
> Thank you in advance!
> 
> -- 
> Best regards,
> Peter

-- 
Mark Moll

[ompl-users] Fwd: ompl-devel post from peter.gschirr@gmail.com requires approval

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

---------- Forwarded message ----------
From: Peter Gschirr <pet...@gm...>
To: omp...@li...
Date: Fri, 25 Nov 2011 14:50:52 +0000
Subject: Problem with OMPL-GUI: ImportError: No module named _util
Dear OMPL-developers,

I installed omplapp-0.9.5 on Ubuntu 11.10 and got the following error when
I tried to start the GUI:

Traceback (most recent call last):
  File "./ompl_app.py", line 37, in <module>
    from ompl.util import OutputHandler, useOutputHandler
  File
"/home/ubuntu/Desktop/omplapp-0.9.5-Source/ompl/py-bindings/ompl/util/__init__.py",
line 4, in <module>
    from _util import *
ImportError: No module named _util

All necessary packages that are mentioned in your help file are installed
and the make also did not report any problems.
I tried it with the 32bit as well as with the 64bit version of Ubuntu, but
no luck. It would be great if you could send me a solution to this problem,
since I would like to show your tool in a presentation.
Thank you in advance!

-- 
Best regards,
Peter

Re: [ompl-users] Can I get the roadmap from the planner say PRM

[Vinay K <vin...@gm...>]

Thanks Ioan.

On Wed, Nov 16, 2011 at 1:15 AM, Ioan Sucan <is...@gm...> wrote:

> Vinay,
>
> The simplest thing to do is inherit from the PRM class and implement the
> constructSolution() function. This function is called by solve() when a
> start & a goal state are found to be in the same connected component.
> Make sure you get the latest repo version of OMPL, so you have the
> function in question is marked as virtual.
> Calling just growRoadmap () does not add the start & goal states to the
> roadmap.
> If you called solve(), getRoadmap() will include the start & goal states.
>
> About your ROS question, the short answer is yes. There is no limitation
> on what you can do in your validity checker. You should look at the
> ompl_ros_interface package, as that is where you will need to make the
> changes.
>
> Ioan
>
>
> On Wed, Nov 16, 2011 at 6:39 AM, Vinay K <vin...@gm...> wrote:
>
>> Hi Ioan,
>>
>> Thanks for your reply. You interpreted my problem very well. I just want
>> to replace the path search function (A* and its variants) with my own
>> search algorithm.
>>
>> Given a start and goal state, first I want to generate roadmap (say using
>> PRM) using your ompl. This roadmap includes start and goal states. Once the
>> roadmap is created then I can use my path search algorithm on the top of
>> that and return path.
>>
>> Can you please tell me the best possible way to do that?  Do I need
>> to override the constructSolution() step of PRM? It seems that you make the
>> roadmap and connect start and goal states in "solve()" function, In that
>> case roadmap given by PRM::getRoadmap() function doesn't include goal and
>> start states??
>>
>> Also I have one more question: If I am using ompl with ros then defining
>> a "bool StateValidityChecker(state)" function and returning the addresss of
>> this function to ompl 'll do the work? And I can do state validity check
>> within this function using costmap, octree..etc?
>>
>> Thanks,
>> Vinay
>>
>>
>>
>>
>>
>>
>> On Tue, Nov 15, 2011 at 12:25 AM, Ioan Sucan <is...@gm...> wrote:
>>
>>> Hello Vinay,
>>>
>>> I am not sure what you mean when you say you want a roadmap in exchange
>>> for a start & goal.
>>> You can certainly call the PRM::getRoadmap() function which will return
>>> a boost graph of the roadmap that is currently in use for the planner. You
>>> can grow this roadmap by calling the growRoadmap function too, no need fo
>>> start & goal states. The start & goal are needed when you do solve().
>>> It seems what you would like to do is override the constructSolution()
>>> step of PRM. That function is not currently virtual, but if you would like
>>> me to make it virtual, so you can inherit from PRM and just change the path
>>> search step, I can do so. Let me know.
>>>
>>> Ioan
>>>
>>>
>>> On Tue, Nov 15, 2011 at 5:46 AM, Vinay K <vin...@gm...> wrote:
>>>
>>>> Hello,
>>>>
>>>> I have designed a new planner which 'll replace A* (and its variants)
>>>> to search for the path from the generated roadmap.
>>>> I haven't ventured that much into ompl files. I am curious to know is
>>>> there any way global planner (say PRM) can return
>>>> the roadmap instead of path. Is there any function which can return
>>>> roadmap in return of "start" and "goal" given that "statevaliditychecker"
>>>> has been set?
>>>>
>>>> Thanks,
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>>>
>>>>
>>>
>>
>

Re: [ompl-users] Can I get the roadmap from the planner say PRM

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

Vinay,

The simplest thing to do is inherit from the PRM class and implement the
constructSolution() function. This function is called by solve() when a
start & a goal state are found to be in the same connected component.
Make sure you get the latest repo version of OMPL, so you have the function
in question is marked as virtual.
Calling just growRoadmap () does not add the start & goal states to the
roadmap.
If you called solve(), getRoadmap() will include the start & goal states.

About your ROS question, the short answer is yes. There is no limitation on
what you can do in your validity checker. You should look at the
ompl_ros_interface package, as that is where you will need to make the
changes.

Ioan

On Wed, Nov 16, 2011 at 6:39 AM, Vinay K <vin...@gm...> wrote:

> Hi Ioan,
>
> Thanks for your reply. You interpreted my problem very well. I just want
> to replace the path search function (A* and its variants) with my own
> search algorithm.
>
> Given a start and goal state, first I want to generate roadmap (say using
> PRM) using your ompl. This roadmap includes start and goal states. Once the
> roadmap is created then I can use my path search algorithm on the top of
> that and return path.
>
> Can you please tell me the best possible way to do that?  Do I need
> to override the constructSolution() step of PRM? It seems that you make the
> roadmap and connect start and goal states in "solve()" function, In that
> case roadmap given by PRM::getRoadmap() function doesn't include goal and
> start states??
>
> Also I have one more question: If I am using ompl with ros then defining a
> "bool StateValidityChecker(state)" function and returning the addresss of
> this function to ompl 'll do the work? And I can do state validity check
> within this function using costmap, octree..etc?
>
> Thanks,
> Vinay
>
>
>
>
>
>
> On Tue, Nov 15, 2011 at 12:25 AM, Ioan Sucan <is...@gm...> wrote:
>
>> Hello Vinay,
>>
>> I am not sure what you mean when you say you want a roadmap in exchange
>> for a start & goal.
>> You can certainly call the PRM::getRoadmap() function which will return a
>> boost graph of the roadmap that is currently in use for the planner. You
>> can grow this roadmap by calling the growRoadmap function too, no need fo
>> start & goal states. The start & goal are needed when you do solve().
>> It seems what you would like to do is override the constructSolution()
>> step of PRM. That function is not currently virtual, but if you would like
>> me to make it virtual, so you can inherit from PRM and just change the path
>> search step, I can do so. Let me know.
>>
>> Ioan
>>
>>
>> On Tue, Nov 15, 2011 at 5:46 AM, Vinay K <vin...@gm...> wrote:
>>
>>> Hello,
>>>
>>> I have designed a new planner which 'll replace A* (and its variants) to
>>> search for the path from the generated roadmap.
>>> I haven't ventured that much into ompl files. I am curious to know is
>>> there any way global planner (say PRM) can return
>>> the roadmap instead of path. Is there any function which can return
>>> roadmap in return of "start" and "goal" given that "statevaliditychecker"
>>> has been set?
>>>
>>> Thanks,
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>>
>>>
>>
>

Re: [ompl-users] Can I get the roadmap from the planner say PRM

[Vinay K <vin...@gm...>]

Hi Ioan,

Thanks for your reply. You interpreted my problem very well. I just want to
replace the path search function (A* and its variants) with my own search
algorithm.

Given a start and goal state, first I want to generate roadmap (say using
PRM) using your ompl. This roadmap includes start and goal states. Once the
roadmap is created then I can use my path search algorithm on the top of
that and return path.

Can you please tell me the best possible way to do that?  Do I need
to override the constructSolution() step of PRM? It seems that you make the
roadmap and connect start and goal states in "solve()" function, In that
case roadmap given by PRM::getRoadmap() function doesn't include goal and
start states??

Also I have one more question: If I am using ompl with ros then defining a
"bool StateValidityChecker(state)" function and returning the addresss of
this function to ompl 'll do the work? And I can do state validity check
within this function using costmap, octree..etc?

Thanks,
Vinay






On Tue, Nov 15, 2011 at 12:25 AM, Ioan Sucan <is...@gm...> wrote:

> Hello Vinay,
>
> I am not sure what you mean when you say you want a roadmap in exchange
> for a start & goal.
> You can certainly call the PRM::getRoadmap() function which will return a
> boost graph of the roadmap that is currently in use for the planner. You
> can grow this roadmap by calling the growRoadmap function too, no need fo
> start & goal states. The start & goal are needed when you do solve().
> It seems what you would like to do is override the constructSolution()
> step of PRM. That function is not currently virtual, but if you would like
> me to make it virtual, so you can inherit from PRM and just change the path
> search step, I can do so. Let me know.
>
> Ioan
>
>
> On Tue, Nov 15, 2011 at 5:46 AM, Vinay K <vin...@gm...> wrote:
>
>> Hello,
>>
>> I have designed a new planner which 'll replace A* (and its variants) to
>> search for the path from the generated roadmap.
>> I haven't ventured that much into ompl files. I am curious to know is
>> there any way global planner (say PRM) can return
>> the roadmap instead of path. Is there any function which can return
>> roadmap in return of "start" and "goal" given that "statevaliditychecker"
>> has been set?
>>
>> Thanks,
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>>
>

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

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

---------- Forwarded message ----------
From: Ioan Sucan <is...@gm...>
Date: Tue, Nov 15, 2011 at 3:35 PM
Subject: Re: [ompl-users] Implementing ControlSampler::sampleTo()
To: Simon Chamberland <Sim...@us...>


Simon,

Changes are pushed now. r1271.
Let me know if you need anything else.

Ioan



2011/11/15 Simon Chamberland <Sim...@us...>

>  Hey Ioan,****
>
> ** **
>
> That sounds like a better solution! I believe I have an older version as I
> don’t see any function in StateSpace to set a custom StateSamplerAllocator.
> ****
>
> ** **
>
> So yes please go ahead with the modification, and I’ll 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(&allocMyControlSampler,
> 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:
> >         > 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
> >
>
> ****
>
> ** **
>

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

[Simon C. <Sim...@US...>]

Hey Ioan,

 

That sounds like a better solution! I believe I have an older version as I
don’t see any function in StateSpace to set a custom StateSamplerAllocator.

 

So yes please go ahead with the modification, and I’ll 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:
>         > 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
>



 

Re: [ompl-users] Can I get the roadmap from the planner say PRM

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

Hello Vinay,

I am not sure what you mean when you say you want a roadmap in exchange for
a start & goal.
You can certainly call the PRM::getRoadmap() function which will return a
boost graph of the roadmap that is currently in use for the planner. You
can grow this roadmap by calling the growRoadmap function too, no need fo
start & goal states. The start & goal are needed when you do solve().
It seems what you would like to do is override the constructSolution() step
of PRM. That function is not currently virtual, but if you would like me to
make it virtual, so you can inherit from PRM and just change the path
search step, I can do so. Let me know.

Ioan


> On Tue, Nov 15, 2011 at 5:46 AM, Vinay K <vin...@gm...> wrote:
>
>> Hello,
>>
>> I have designed a new planner which 'll replace A* (and its variants) to
>> search for the path from the generated roadmap.
>> I haven't ventured that much into ompl files. I am curious to know is
>> there any way global planner (say PRM) can return
>> the roadmap instead of path. Is there any function which can return
>> roadmap in return of "start" and "goal" given that "statevaliditychecker"
>> has been set?
>>
>> Thanks,
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>>
>

[ompl-users] Can I get the roadmap from the planner say PRM

[Vinay K <vin...@gm...>]

Hello,

I have designed a new planner which 'll replace A* (and its variants) to
search for the path from the generated roadmap.
I haven't ventured that much into ompl files. I am curious to know is there
any way global planner (say PRM) can return
the roadmap instead of path. Is there any function which can return roadmap
in return of "start" and "goal" given that "statevaliditychecker"
has been set?

Thanks,

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

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

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(&allocMyControlSampler,
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:
> >         > 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
> >
>
>
>

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

[Simon C. <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:
>         > 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
> 

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

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

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
>

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

[Mark M. <mm...@ri...>]

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

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

[Simon C. <Sim...@US...>]

Hi,

 

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?

 

Thanks,

 

Simon Chamberland

Master’s student – Université de Sherbrooke

 

 

[ompl-users] Join this list

[Weiran Z. <zha...@um...>]

Weiran Zhao
Computer Science Department
Indiana University Bloomington

Re: [ompl-users] ControlSampler extension / Tree extraction

[Joerg M. <mue...@in...>]

Hello Ioan,

I tested the added functions - they worked.
For compiling the implementations of my blimp models for OMPL, I needed 
to apply the attached patch.

For visualization I need to extract the tree(s) built during state space 
exploration. Is there an easy way to find the root node(s)/start 
state(s) of that tree(s) in ompl::base::PlannerData? For the RRT it 
seems to be the first element of the vector of states. For KPIECE I 
decided to search for states which do not have a parent state. Is there 
a more efficient solution for that problem?

Joerg


On 01.10.2011 21:07, Ioan Sucan wrote:
> Hello Joerg,
>
> I have added a few variants of a sampleTo() function to the
> ControlSampler (pushed to sourceforge). If you are building from the
> repository, you should be able to use the updated code with RRT. I made
> no updates for KPIECE so far.
> Please let us know if there is anything else you need.
>
> Ioan
>
>
> On Mon, Sep 26, 2011 at 9:09 AM, Ioan Sucan <is...@gm...
> <mailto:is...@gm...>> wrote:
>
>
>
>     On Mon, Sep 26, 2011 at 9:02 AM, Joerg Mueller
>     <mue...@in...
>     <mailto:mue...@in...>> wrote:
>
>         Hello Ioan,
>
>         I would suggest to add that function (with a fallback default
>         implementation) and also change the RRT (and KPIECE?)
>         implementation to use it.
>
>     Yes, you are correct. I meant to include this too. It is clear how
>     to do this for RRT. I'll try to think about something reasonable to
>     do for KPIECE.
>
>     Ioan
>
>         I will then override that function in the implementation for my
>         blimp robot.
>
>         Thank you.
>
>         Joerg
>
>
>         Am 26.09.2011 08 <tel:26.09.2011%2008>:49, schrieb Ioan Sucan:
>
>             Hello Joerg!
>
>             Thank you for the reminder! The solution I had in mind when
>             we talked at
>             the tutorial is what Mark said. The function he is talking
>             about will be
>             in the repository soon. Would that be sufficient for your needs?
>
>             Ioan
>
>
>             On Mon, Sep 26, 2011 at 8:31 AM, Mark Moll <mm...@ri...
>             <mailto:mm...@ri...>
>             <mailto:mm...@ri... <mailto:mm...@ri...>>> wrote:
>
>                 Joerg,
>
>                 That would be very useful, but in general this is very
>             hard. Given
>                 some system of the form qdot = f(q,u) it is impossible
>             for OMPL to
>                 figure out how to steer the system towards a desired
>             state. However,
>                 for specific systems (such as cars) it may be possible
>             to do this.
>                 This requires a small change to the ControlSampler API
>             to create a
>                 member function that takes as input the state that you
>             want to steer
>                 the system to.
>
>                 On Sep 25, 2011, at 6:49 PM, Joerg Mueller wrote:
>
>              > Hi Ioan,
>              >
>              > as previously discussed, I would like to request for an
>             extension
>                 of the
>              > ControlSampler for a "smart" sampling of a control that
>             moves the
>                 robot
>              > from the tree state towards the sampled/desired state in RRT
>                 planning.
>              >
>              > Regards,
>              > Joerg
>              >
>              > --
>              >
>              > ..............................__....................
>              >  Joerg Mueller, Dipl. Inf.
>              >  Albert-Ludwigs-University of Freiburg
>              >  Department of Computer Science
>              >  Autonomous Intelligent Systems
>              >  Georges-Koehler-Allee 079
>              >  D-79110 Freiburg, Germany
>              >  Phone: +49-761-203-8005 <tel:%2B49-761-203-8005>
>             <tel:%2B49-761-203-8005>
>              >  Fax: +49-761-203-8007 <tel:%2B49-761-203-8007>
>             <tel:%2B49-761-203-8007>
>
>              > muellerj@informatik.uni-__freiburg.de
>             <mailto:mue...@in...>
>             <mailto:muellerj@informatik.__uni-freiburg.de
>             <mailto:mue...@in...>>
>
>              > http://www.informatik.uni-__freiburg.de/~muellerj/
>             <http://www.informatik.uni-freiburg.de/%7Emuellerj/>
>             <http://www.informatik.uni-__freiburg.de/%7Emuellerj/
>             <http://www.informatik.uni-freiburg.de/%7Emuellerj/>>
>
>              > ..............................__....................
>              >
>              >
>
>               ------------------------------__------------------------------__------------------
>              > All the data continuously generated in your IT infrastructure
>                 contains a
>              > definitive record of customers, application performance,
>             security
>              > threats, fraudulent activity and more. Splunk takes this
>             data and
>                 makes
>              > sense of it. Business sense. IT sense. Common sense.
>              > http://p.sf.net/sfu/splunk-__d2dcopy1
>             <http://p.sf.net/sfu/splunk-d2dcopy1>
>              > _________________________________________________
>              > ompl-users mailing list
>              > omp...@li...urceforge.__net
>             <mailto:omp...@li...>
>             <mailto:ompl-users@lists.__sourceforge.net
>             <mailto:omp...@li...>>
>
>              > https://lists.sourceforge.net/__lists/listinfo/ompl-users
>             <https://lists.sourceforge.net/lists/listinfo/ompl-users>
>              >
>
>                 --
>                 Mark Moll
>
>
>
>
>
>               ------------------------------__------------------------------__------------------
>                 All the data continuously generated in your IT
>             infrastructure contains a
>                 definitive record of customers, application performance,
>             security
>                 threats, fraudulent activity and more. Splunk takes this
>             data and makes
>                 sense of it. Business sense. IT sense. Common sense.
>             http://p.sf.net/sfu/splunk-__d2dcopy1
>             <http://p.sf.net/sfu/splunk-d2dcopy1>
>                 _________________________________________________
>                 ompl-users mailing list
>             omp...@li...urceforge.__net
>             <mailto:omp...@li...>
>             <mailto:ompl-users@lists.__sourceforge.net
>             <mailto:omp...@li...>>
>
>             https://lists.sourceforge.net/__lists/listinfo/ompl-users
>             <https://lists.sourceforge.net/lists/listinfo/ompl-users>
>
>
>
>         --
>
>         ..............................__....................
>           Joerg Mueller, Dipl. Inf.
>           Albert-Ludwigs-University of Freiburg
>           Department of Computer Science
>           Autonomous Intelligent Systems
>           Georges-Koehler-Allee 079
>           D-79110 Freiburg, Germany
>           Phone: +49-761-203-8005 <tel:%2B49-761-203-8005>
>         muellerj@informatik.uni-__freiburg.de
>         <mailto:mue...@in...>
>         http://www.informatik.uni-__freiburg.de/~muellerj/
>         <http://www.informatik.uni-freiburg.de/%7Emuellerj/>
>         ..............................__....................
>
>
>

-- 

..................................................
  Joerg Mueller, Dipl. Inf.
  Albert-Ludwigs-University of Freiburg
  Department of Computer Science
  Autonomous Intelligent Systems
  Georges-Koehler-Allee 079
  D-79110 Freiburg, Germany
  Phone: +49-761-203-8005
  Fax: +49-761-203-8007
  mue...@in...
  http://www.informatik.uni-freiburg.de/~muellerj/
..................................................

Re: [ompl-users] Cannot start GUI

[Mark M. <mm...@ri...>]

Can you try out the script I just sent? To be completely on the safe side, it’s best to remove the previously generated python bindings: 

	rm -rf py-bindings/bindings ompl/py-bindings/bindings

Next, regenerate and rebuild in your build directory:

	cd build/Release
	make update_bindings && make

On Oct 13, 2011, at 5:07 PM, Alvaro Retortillo wrote:

> Thanks for your answer.
> 
> I using mac os (10.6.8)
> 
> I have not installed (make install) any of the versions of ompl I have been using (0.9.3, 0.9.4 and now 0.9.5)
> I run it in the gui directory.
> 
> I could not install py27-pyqt4: something with port installer... So I am using PySide, which seems to be enough to compile.
> 
> One more thing, when compilling I get these warnings:
> ld: warning: duplicate dylib /opt/local/lib/libboost_filesystem-mt.dylib
> ld: warning: duplicate dylib /opt/local/lib/libboost_system-mt.dylib
> ld: warning: duplicate dylib /opt/local/lib/libPQP.dylib
> 
> Hope it helps.
> 
> Alvaro Retortillo.
> ¡Saludos!
> 
> 
> On Thu, Oct 13, 2011 at 11:05 PM, Mark Moll <mm...@ri...> wrote:
> Which OS are you using? Can you email me the CMakeCache.txt and pyplusplus*.log files from your build directory? You don’t have any other versions of OMPL installed, do you?
> 
> On Oct 13, 2011, at 11:26 AM, Alvaro Retortillo wrote:
> 
> > Hi all!
> >
> > Reciently I upgraded to 0.9.5. I updated all software used by omplapp (as it is detailed on the installation page, I also configured python to 2.7) I compiled it (cmake, make update_bindings, make, make doc)  Everything seemed to work fine. Tests and demos work fine.
> >
> > The only problem is that the ompl_app.py script is not working:
> >
> > Alvaro-2:gui alvaro$ /opt/local/bin/python --version
> > Python 2.7.2
> > Alvaro-2:gui alvaro$ /opt/local/bin/python ompl_app.py
> > Traceback (most recent call last):
> >   File "ompl_app.py", line 37, in <module>
> >     from ompl.util import OutputHandler, useOutputHandler
> > ImportError: cannot import name OutputHandler
> > Alvaro-2:gui alvaro$
> >
> > Thank you all!
> >
> > Alvaro Retortillo.
> > ¡Saludos!
> > ------------------------------------------------------------------------------
> > All the data continuously generated in your IT infrastructure contains a
> > definitive record of customers, application performance, security
> > threats, fraudulent activity and more. Splunk takes this data and makes
> > sense of it. Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2d-oct_______________________________________________
> > ompl-users mailing list
> > omp...@li...
> > https://lists.sourceforge.net/lists/listinfo/ompl-users
> 
> --
> Mark Moll
> 
> 
> 
> 
> <CMakeCache.txt><pyplusplus_app.log>

-- 
Mark Moll

[ompl-users] small bug in python binding generation on *some* platforms

[Mark M. <mm...@ri...>]

We just discovered that for some architectures (or some versions of Boost) the generation of python bindings fails. If “make update_bindings” failed on your machine and you’re pretty sure you have all dependencies installed, then replace ompl/py-bindings/generate_bindings.py with the attached script and type “make update_bindings” in your build directory. This fix will be included in the next release.

-- 
Mark Moll

Re: [ompl-users] Cannot start GUI

[Alvaro R. <ret...@us...>]

# This is the CMakeCache file.
# For build in directory: /Users/alvaro/Documents/Proyectos/PRP/omplapp-0.9.5-Source/build/Debug
# It was generated by CMake: /opt/local/bin/cmake
# You can edit this file to change values found and used by cmake.
# If you do not want to change any of the values, simply exit the editor.
# If you do want to change a value, simply edit, save, and exit the editor.
# The syntax for the file is as follows:
# KEY:TYPE=VALUE
# KEY is the name of a variable in the cache.
# TYPE is a hint to GUI's for the type of VALUE, DO NOT EDIT TYPE!.
# VALUE is the current value for the KEY.

########################
# EXTERNAL cache entries
########################

//Location of 3D asset importer header file directory
ASSIMP_INCLUDE_DIR:PATH=/opt/local/include/assimp

//Location of 3D asset importer library
ASSIMP_LIBRARY:FILEPATH=/opt/local/lib/libassimp.dylib

//The Boost DATE_TIME library
Boost_DATE_TIME_LIBRARY:FILEPATH=/opt/local/lib/libboost_date_time-mt.dylib

//Boost date_time library (debug)
Boost_DATE_TIME_LIBRARY_DEBUG:FILEPATH=/opt/local/lib/libboost_date_time-mt.dylib

//Boost date_time library (release)
Boost_DATE_TIME_LIBRARY_RELEASE:FILEPATH=/opt/local/lib/libboost_date_time-mt.dylib

//The directory containing a CMake configuration file for Boost.
Boost_DIR:PATH=Boost_DIR-NOTFOUND

//The Boost FILESYSTEM library
Boost_FILESYSTEM_LIBRARY:FILEPATH=/opt/local/lib/libboost_filesystem-mt.dylib

//Boost filesystem library (debug)
Boost_FILESYSTEM_LIBRARY_DEBUG:FILEPATH=/opt/local/lib/libboost_filesystem-mt.dylib

//Boost filesystem library (release)
Boost_FILESYSTEM_LIBRARY_RELEASE:FILEPATH=/opt/local/lib/libboost_filesystem-mt.dylib

//Path to a file.
Boost_INCLUDE_DIR:PATH=/opt/local/include

//Boost library directory
Boost_LIBRARY_DIRS:FILEPATH=/opt/local/lib

//The Boost PYTHON library
Boost_PYTHON_LIBRARY:FILEPATH=/opt/local/lib/libboost_python-mt.dylib

//Boost python library (debug)
Boost_PYTHON_LIBRARY_DEBUG:FILEPATH=/opt/local/lib/libboost_python-mt.dylib

//Boost python library (release)
Boost_PYTHON_LIBRARY_RELEASE:FILEPATH=/opt/local/lib/libboost_python-mt.dylib

//The Boost SYSTEM library
Boost_SYSTEM_LIBRARY:FILEPATH=/opt/local/lib/libboost_system-mt.dylib

//Boost system library (debug)
Boost_SYSTEM_LIBRARY_DEBUG:FILEPATH=/opt/local/lib/libboost_system-mt.dylib

//Boost system library (release)
Boost_SYSTEM_LIBRARY_RELEASE:FILEPATH=/opt/local/lib/libboost_system-mt.dylib

//The Boost THREAD library
Boost_THREAD_LIBRARY:FILEPATH=/opt/local/lib/libboost_thread-mt.dylib

//Boost thread library (debug)
Boost_THREAD_LIBRARY_DEBUG:FILEPATH=/opt/local/lib/libboost_thread-mt.dylib

//Boost thread library (release)
Boost_THREAD_LIBRARY_RELEASE:FILEPATH=/opt/local/lib/libboost_thread-mt.dylib

//Path to a program.
CMAKE_AR:FILEPATH=/usr/bin/ar

//Choose the type of build, options are: None(CMAKE_CXX_FLAGS or
// CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel.
CMAKE_BUILD_TYPE:STRING=Debug

//Enable/Disable color output during build.
CMAKE_COLOR_MAKEFILE:BOOL=ON

//CXX compiler.
CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/c++

//Flags used by the compiler during all build types.
CMAKE_CXX_FLAGS:STRING=

//Flags used by the compiler during debug builds.
CMAKE_CXX_FLAGS_DEBUG:STRING=-g

//Flags used by the compiler during release minsize builds.
CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG

//Flags used by the compiler during release builds (/MD /Ob1 /Oi
// /Ot /Oy /Gs will produce slightly less optimized but smaller
// files).
CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG

//Flags used by the compiler during Release with Debug Info builds.
CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g

//C compiler.
CMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc

//Flags used by the compiler during all build types.
CMAKE_C_FLAGS:STRING=

//Flags used by the compiler during debug builds.
CMAKE_C_FLAGS_DEBUG:STRING=-g

//Flags used by the compiler during release minsize builds.
CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG

//Flags used by the compiler during release builds (/MD /Ob1 /Oi
// /Ot /Oy /Gs will produce slightly less optimized but smaller
// files).
CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG

//Flags used by the compiler during Release with Debug Info builds.
CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g

//Flags used by the linker.
CMAKE_EXE_LINKER_FLAGS:STRING=' '

//Flags used by the linker during debug builds.
CMAKE_EXE_LINKER_FLAGS_DEBUG:STRING=

//Flags used by the linker during release minsize builds.
CMAKE_EXE_LINKER_FLAGS_MINSIZEREL:STRING=

//Flags used by the linker during release builds.
CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING=

//Flags used by the linker during Release with Debug Info builds.
CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO:STRING=

//Enable/Disable output of compile commands during generation.
CMAKE_EXPORT_COMPILE_COMMANDS:BOOL=OFF

//Path to a program.
CMAKE_INSTALL_NAME_TOOL:FILEPATH=/usr/bin/install_name_tool

//Install path prefix, prepended onto install directories.
CMAKE_INSTALL_PREFIX:PATH=/usr/local

//Path to a program.
CMAKE_LINKER:FILEPATH=/usr/bin/ld

//Path to a program.
CMAKE_MAKE_PROGRAM:FILEPATH=/usr/bin/make

//Flags used by the linker during the creation of modules.
CMAKE_MODULE_LINKER_FLAGS:STRING=' '

//Flags used by the linker during debug builds.
CMAKE_MODULE_LINKER_FLAGS_DEBUG:STRING=

//Flags used by the linker during release minsize builds.
CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL:STRING=

//Flags used by the linker during release builds.
CMAKE_MODULE_LINKER_FLAGS_RELEASE:STRING=

//Flags used by the linker during Release with Debug Info builds.
CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO:STRING=

//Path to a program.
CMAKE_NM:FILEPATH=/usr/bin/nm

//Path to a program.
CMAKE_OBJCOPY:FILEPATH=CMAKE_OBJCOPY-NOTFOUND

//Path to a program.
CMAKE_OBJDUMP:FILEPATH=CMAKE_OBJDUMP-NOTFOUND

//Build architectures for OSX
CMAKE_OSX_ARCHITECTURES:STRING=

//Minimum OS X version to target for deployment (at runtime); newer
// APIs weak linked. Set to empty string for default value.
CMAKE_OSX_DEPLOYMENT_TARGET:STRING=

//The product will be built against the headers and libraries located
// inside the indicated SDK.
CMAKE_OSX_SYSROOT:PATH=/Developer/SDKs/MacOSX10.6.sdk

//Value Computed by CMake
CMAKE_PROJECT_NAME:STATIC=omplapp

//Path to a program.
CMAKE_RANLIB:FILEPATH=/usr/bin/ranlib

//Flags used by the linker during the creation of dll's.
CMAKE_SHARED_LINKER_FLAGS:STRING=' '

//Flags used by the linker during debug builds.
CMAKE_SHARED_LINKER_FLAGS_DEBUG:STRING=

//Flags used by the linker during release minsize builds.
CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL:STRING=

//Flags used by the linker during release builds.
CMAKE_SHARED_LINKER_FLAGS_RELEASE:STRING=

//Flags used by the linker during Release with Debug Info builds.
CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO:STRING=

//If set, runtime paths are not added when using shared libraries.
CMAKE_SKIP_RPATH:BOOL=NO

//Path to a program.
CMAKE_STRIP:FILEPATH=/usr/bin/strip

//If true, cmake will use relative paths in makefiles and projects.
CMAKE_USE_RELATIVE_PATHS:BOOL=OFF

//If this value is on, makefiles will be generated without the
// .SILENT directive, and all commands will be echoed to the console
// during the make.  This is useful for debugging only. With Visual
// Studio IDE projects all commands are done without /nologo.
CMAKE_VERBOSE_MAKEFILE:BOOL=FALSE

//Graphviz Dot tool for using Doxygen
DOXYGEN_DOT_EXECUTABLE:FILEPATH=/opt/local/bin/dot

DOXYGEN_DOT_PATH:FILEPATH=/opt/local/bin

//Doxygen documentation generation tool (http://www.doxygen.org)
DOXYGEN_EXECUTABLE:FILEPATH=/opt/local/bin/doxygen

//Location of ODE's drawstuff header files
DRAWSTUFF_INCLUDE_DIR:PATH=DRAWSTUFF_INCLUDE_DIR-NOTFOUND

//Location of ODE's drawstuff library
DRAWSTUFF_LIBRARY:FILEPATH=DRAWSTUFF_LIBRARY-NOTFOUND

//Path to a program.
GCCXML:FILEPATH=/opt/local/bin/gccxml

//Path to a file.
GTEST_INCLUDE_DIR:PATH=/opt/local/include

//Path to a library.
GTEST_LIBRARY:FILEPATH=/opt/local/lib/libgtest.dylib

//Path to a library.
GTEST_LIBRARY_DEBUG:FILEPATH=GTEST_LIBRARY_DEBUG-NOTFOUND

//Path to a library.
GTEST_MAIN_LIBRARY:FILEPATH=/opt/local/lib/libgtest_main.dylib

//Path to a library.
GTEST_MAIN_LIBRARY_DEBUG:FILEPATH=GTEST_MAIN_LIBRARY_DEBUG-NOTFOUND

//Path to a file.
ODE_INCLUDE_DIR:PATH=/opt/local/include/ode

//Path to a library.
ODE_LIBRARY:FILEPATH=/opt/local/lib/libode.dylib

//Build OMPL.app documentation
OMPLAPP_BUILD_DOC:BOOL=ON

//Build OMPL demos
OMPL_BUILD_DEMOS:BOOL=ON

//Build OMPL Python bindings
OMPL_BUILD_PYBINDINGS:BOOL=ON

//Build OMPL Python tests
OMPL_BUILD_PYTESTS:BOOL=ON

//Build OMPL tests
OMPL_BUILD_TESTS:BOOL=ON

//Path to directory with auxiliary CMake scripts for OMPL
OMPL_CMAKE_UTIL_DIR:FILEPATH=/Users/alvaro/Documents/Proyectos/PRP/omplapp-0.9.5-Source/ompl/CMakeModules

//Enable RRTstar contrib
OMPL_CONTRIB_RRTSTAR_CONTRIB:BOOL=ON

//Enable SampleContrib
OMPL_CONTRIB_SAMPLECONTRIB:BOOL=OFF

//Relative path to directory where demos will be installed
OMPL_DEMO_INSTALL_DIR:STRING=share/ompl/demos

//Relative path to directory where documentation will be installed
OMPL_DOC_INSTALL_DIR:STRING=share/ompl/doc

//Path to directory where OMPL python modules will be installed
OMPL_PYTHON_INSTALL_DIR:STRING=Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages

//Include for OpenGL on OSX
OPENGL_INCLUDE_DIR:PATH=/System/Library/Frameworks/OpenGL.framework

//OpenGL lib for OSX
OPENGL_gl_LIBRARY:FILEPATH=/System/Library/Frameworks/OpenGL.framework

//AGL lib for OSX
OPENGL_glu_LIBRARY:FILEPATH=/System/Library/Frameworks/AGL.framework

//Location of PQP proximity query header files
PQP_INCLUDE_DIR:PATH=/opt/local/include/PQP

//Location of PQP proximity query library
PQP_LIBRARY:FILEPATH=/opt/local/lib/libPQP.dylib

//Location of python executable to use
PYTHON_EXEC:FILEPATH=/opt/local/bin/python

//Python include directories
PYTHON_INCLUDE_DIRS:PATH=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7

//Python libraries
PYTHON_LIBRARIES:FILEPATH=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config/libpython2.7.dylib

//Whether the OMPL Python modules can be built
PY_OMPL_COMPILE:BOOL=ON

//Whether the C++ code for the OMPL Python module can be generated
PY_OMPL_GENERATE:BOOL=ON

//Location of Python module OpenGL
PY_OPENGL:STRING=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/OpenGL

//Location of Python module pygccxml
PY_PYGCCXML:STRING=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pygccxml

//Location of Python module pyplusplus
PY_PYPLUSPLUS:STRING=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pyplusplus

//Location of Python module PySide
PY_PYSIDE:STRING=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PySide

//The Ruby arch dir
RUBY_ARCH_DIR:PATH=/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin10.0

//Path to a file.
RUBY_CONFIG_INCLUDE_DIR:PATH=/System/Library/Frameworks/ruby.framework

//Path to a program.
RUBY_EXECUTABLE:FILEPATH=/usr/bin/ruby

//Vendor Ruby is available
RUBY_HAS_VENDOR_RUBY:BOOL=

//The Ruby header dir (1.9)
RUBY_HDR_DIR:PATH=nil

//Path to a file.
RUBY_INCLUDE_DIR:PATH=/System/Library/Frameworks/Ruby.framework/Headers

//Path to a library.
RUBY_LIBRARY:FILEPATH=/System/Library/Frameworks/ruby.framework

//The Ruby lib dir
RUBY_POSSIBLE_LIB_DIR:PATH=/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib

//The Ruby ruby-lib dir
RUBY_RUBY_LIB_DIR:PATH=/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8

//The Ruby site arch dir
RUBY_SITEARCH_DIR:PATH=/Library/Ruby/Site/1.8/universal-darwin10.0

//The Ruby site lib dir
RUBY_SITELIB_DIR:PATH=/Library/Ruby/Site/1.8

//The Ruby vendor arch dir
RUBY_VENDORARCH_DIR:PATH=

//The Ruby vendor lib dir
RUBY_VENDORLIB_DIR:PATH=

//The Ruby major version
RUBY_VERSION_MAJOR:PATH=1

//The Ruby minor version
RUBY_VERSION_MINOR:PATH=8

//The Ruby patch version
RUBY_VERSION_PATCH:PATH=7

//Path to a program.
_ODE_CONFIG:FILEPATH=/opt/local/bin/ode-config

//Dependencies for the target
ompl_LIB_DEPENDS:STATIC=general;/opt/local/lib/libboost_thread-mt.dylib;general;/opt/local/lib/libboost_date_time-mt.dylib;general;/opt/local/lib/libode.dylib;

//Dependencies for the target
ompl_app_LIB_DEPENDS:STATIC=general;ompl;general;/opt/local/lib/libboost_filesystem-mt.dylib;general;/opt/local/lib/libboost_system-mt.dylib;general;/System/Library/Frameworks/AGL.framework;general;/System/Library/Frameworks/OpenGL.framework;general;/opt/local/lib/libassimp.dylib;general;/opt/local/lib/libPQP.dylib;

//Value Computed by CMake
omplapp_BINARY_DIR:STATIC=/Users/alvaro/Documents/Proyectos/PRP/omplapp-0.9.5-Source/build/Debug

//Value Computed by CMake
omplapp_SOURCE_DIR:STATIC=/Users/alvaro/Documents/Proyectos/PRP/omplapp-0.9.5-Source

//Dependencies for the target
py_ompl_app_LIB_DEPENDS:STATIC=general;ompl;general;ompl_app;general;/opt/local/lib/libboost_python-mt.dylib;general;/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config/libpython2.7.dylib;

//Dependencies for the target
py_ompl_base_LIB_DEPENDS:STATIC=general;ompl;general;/opt/local/lib/libboost_python-mt.dylib;general;/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config/libpython2.7.dylib;

//Dependencies for the target
py_ompl_control_LIB_DEPENDS:STATIC=general;ompl;general;/opt/local/lib/libboost_python-mt.dylib;general;/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config/libpython2.7.dylib;

//Dependencies for the target
py_ompl_geometric_LIB_DEPENDS:STATIC=general;ompl;general;/opt/local/lib/libboost_python-mt.dylib;general;/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config/libpython2.7.dylib;

//Dependencies for the target
py_ompl_util_LIB_DEPENDS:STATIC=general;ompl;general;/opt/local/lib/libboost_python-mt.dylib;general;/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config/libpython2.7.dylib;


########################
# INTERNAL cache entries
########################

//Whether the Boost DATE_TIME library found
Boost_DATE_TIME_FOUND:INTERNAL=ON
//ADVANCED property for variable: Boost_DATE_TIME_LIBRARY
Boost_DATE_TIME_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: Boost_DATE_TIME_LIBRARY_DEBUG
Boost_DATE_TIME_LIBRARY_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: Boost_DATE_TIME_LIBRARY_RELEASE
Boost_DATE_TIME_LIBRARY_RELEASE-ADVANCED:INTERNAL=1
//Whether the Boost FILESYSTEM library found
Boost_FILESYSTEM_FOUND:INTERNAL=ON
//ADVANCED property for variable: Boost_FILESYSTEM_LIBRARY
Boost_FILESYSTEM_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: Boost_FILESYSTEM_LIBRARY_DEBUG
Boost_FILESYSTEM_LIBRARY_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: Boost_FILESYSTEM_LIBRARY_RELEASE
Boost_FILESYSTEM_LIBRARY_RELEASE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: Boost_INCLUDE_DIR
Boost_INCLUDE_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: Boost_LIBRARY_DIRS
Boost_LIBRARY_DIRS-ADVANCED:INTERNAL=1
//The library version string for boost libraries
Boost_LIB_VERSION:INTERNAL=1_47
//Whether the Boost PYTHON library found
Boost_PYTHON_FOUND:INTERNAL=ON
//ADVANCED property for variable: Boost_PYTHON_LIBRARY
Boost_PYTHON_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: Boost_PYTHON_LIBRARY_DEBUG
Boost_PYTHON_LIBRARY_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: Boost_PYTHON_LIBRARY_RELEASE
Boost_PYTHON_LIBRARY_RELEASE-ADVANCED:INTERNAL=1
//Whether the Boost SYSTEM library found
Boost_SYSTEM_FOUND:INTERNAL=ON
//ADVANCED property for variable: Boost_SYSTEM_LIBRARY
Boost_SYSTEM_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: Boost_SYSTEM_LIBRARY_DEBUG
Boost_SYSTEM_LIBRARY_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: Boost_SYSTEM_LIBRARY_RELEASE
Boost_SYSTEM_LIBRARY_RELEASE-ADVANCED:INTERNAL=1
//Whether the Boost THREAD library found
Boost_THREAD_FOUND:INTERNAL=ON
//ADVANCED property for variable: Boost_THREAD_LIBRARY
Boost_THREAD_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: Boost_THREAD_LIBRARY_DEBUG
Boost_THREAD_LIBRARY_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: Boost_THREAD_LIBRARY_RELEASE
Boost_THREAD_LIBRARY_RELEASE-ADVANCED:INTERNAL=1
//The version number for boost libraries
Boost_VERSION:INTERNAL=104700
//ADVANCED property for variable: CMAKE_AR
CMAKE_AR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_BUILD_TOOL
CMAKE_BUILD_TOOL-ADVANCED:INTERNAL=1
//What is the target build tool cmake is generating for.
CMAKE_BUILD_TOOL:INTERNAL=/usr/bin/make
//This is the directory where this CMakeCache.txt was created
CMAKE_CACHEFILE_DIR:INTERNAL=/Users/alvaro/Documents/Proyectos/PRP/omplapp-0.9.5-Source/build/Debug
//Major version of cmake used to create the current loaded cache
CMAKE_CACHE_MAJOR_VERSION:INTERNAL=2
//Minor version of cmake used to create the current loaded cache
CMAKE_CACHE_MINOR_VERSION:INTERNAL=8
//Patch version of cmake used to create the current loaded cache
CMAKE_CACHE_PATCH_VERSION:INTERNAL=6
//ADVANCED property for variable: CMAKE_COLOR_MAKEFILE
CMAKE_COLOR_MAKEFILE-ADVANCED:INTERNAL=1
//Path to CMake executable.
CMAKE_COMMAND:INTERNAL=/opt/local/bin/cmake
//Path to cpack program executable.
CMAKE_CPACK_COMMAND:INTERNAL=/opt/local/bin/cpack
//Path to ctest program executable.
CMAKE_CTEST_COMMAND:INTERNAL=/opt/local/bin/ctest
//ADVANCED property for variable: CMAKE_CXX_COMPILER
CMAKE_CXX_COMPILER-ADVANCED:INTERNAL=1
CMAKE_CXX_COMPILER_WORKS:INTERNAL=1
//ADVANCED property for variable: CMAKE_CXX_FLAGS
CMAKE_CXX_FLAGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_CXX_FLAGS_DEBUG
CMAKE_CXX_FLAGS_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_CXX_FLAGS_MINSIZEREL
CMAKE_CXX_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_CXX_FLAGS_RELEASE
CMAKE_CXX_FLAGS_RELEASE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_CXX_FLAGS_RELWITHDEBINFO
CMAKE_CXX_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_COMPILER
CMAKE_C_COMPILER-ADVANCED:INTERNAL=1
CMAKE_C_COMPILER_WORKS:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_FLAGS
CMAKE_C_FLAGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_FLAGS_DEBUG
CMAKE_C_FLAGS_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_FLAGS_MINSIZEREL
CMAKE_C_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_FLAGS_RELEASE
CMAKE_C_FLAGS_RELEASE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_FLAGS_RELWITHDEBINFO
CMAKE_C_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1
//Result of TRY_COMPILE
CMAKE_DETERMINE_CXX_ABI_COMPILED:INTERNAL=TRUE
//Result of TRY_COMPILE
CMAKE_DETERMINE_C_ABI_COMPILED:INTERNAL=TRUE
//Path to cache edit program executable.
CMAKE_EDIT_COMMAND:INTERNAL=/opt/local/bin/ccmake
//Executable file format
CMAKE_EXECUTABLE_FORMAT:INTERNAL=Unknown
//ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS
CMAKE_EXE_LINKER_FLAGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_DEBUG
CMAKE_EXE_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_MINSIZEREL
CMAKE_EXE_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_RELEASE
CMAKE_EXE_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO
CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_EXPORT_COMPILE_COMMANDS
CMAKE_EXPORT_COMPILE_COMMANDS-ADVANCED:INTERNAL=1
//Name of generator.
CMAKE_GENERATOR:INTERNAL=Unix Makefiles
//Start directory with the top level CMakeLists.txt file for this
// project
CMAKE_HOME_DIRECTORY:INTERNAL=/Users/alvaro/Documents/Proyectos/PRP/omplapp-0.9.5-Source
//ADVANCED property for variable: CMAKE_INSTALL_NAME_TOOL
CMAKE_INSTALL_NAME_TOOL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_LINKER
CMAKE_LINKER-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_MAKE_PROGRAM
CMAKE_MAKE_PROGRAM-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS
CMAKE_MODULE_LINKER_FLAGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_DEBUG
CMAKE_MODULE_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL
CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_RELEASE
CMAKE_MODULE_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO
CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_NM
CMAKE_NM-ADVANCED:INTERNAL=1
//number of local generators
CMAKE_NUMBER_OF_LOCAL_GENERATORS:INTERNAL=14
//ADVANCED property for variable: CMAKE_OBJCOPY
CMAKE_OBJCOPY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_OBJDUMP
CMAKE_OBJDUMP-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_RANLIB
CMAKE_RANLIB-ADVANCED:INTERNAL=1
//Path to CMake installation.
CMAKE_ROOT:INTERNAL=/opt/local/share/cmake-2.8
//ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_DEBUG
CMAKE_SHARED_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL
CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_RELEASE
CMAKE_SHARED_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO
CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_SKIP_RPATH
CMAKE_SKIP_RPATH-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STRIP
CMAKE_STRIP-ADVANCED:INTERNAL=1
//uname command
CMAKE_UNAME:INTERNAL=/usr/bin/uname
//ADVANCED property for variable: CMAKE_USE_RELATIVE_PATHS
CMAKE_USE_RELATIVE_PATHS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_VERBOSE_MAKEFILE
CMAKE_VERBOSE_MAKEFILE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: DOXYGEN_DOT_EXECUTABLE
DOXYGEN_DOT_EXECUTABLE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: DOXYGEN_DOT_PATH
DOXYGEN_DOT_PATH-ADVANCED:INTERNAL=1
//ADVANCED property for variable: DOXYGEN_EXECUTABLE
DOXYGEN_EXECUTABLE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: DRAWSTUFF_INCLUDE_DIR
DRAWSTUFF_INCLUDE_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: DRAWSTUFF_LIBRARY
DRAWSTUFF_LIBRARY-ADVANCED:INTERNAL=1
//Details about finding GTest
FIND_PACKAGE_MESSAGE_DETAILS_GTest:INTERNAL=[/opt/local/lib/libgtest.dylib][/opt/local/include][/opt/local/lib/libgtest_main.dylib][v()]
//Details about finding OpenGL
FIND_PACKAGE_MESSAGE_DETAILS_OpenGL:INTERNAL=[/System/Library/Frameworks/OpenGL.framework][v()]
//Details about finding PY_OpenGL
FIND_PACKAGE_MESSAGE_DETAILS_PY_OpenGL:INTERNAL=[/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/OpenGL][v()]
//Details about finding PY_PySide
FIND_PACKAGE_MESSAGE_DETAILS_PY_PySide:INTERNAL=[/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PySide][v()]
//Details about finding PY_pygccxml
FIND_PACKAGE_MESSAGE_DETAILS_PY_pygccxml:INTERNAL=[/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pygccxml][v()]
//Details about finding PY_pyplusplus
FIND_PACKAGE_MESSAGE_DETAILS_PY_pyplusplus:INTERNAL=[/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pyplusplus][v()]
//Details about finding Python
FIND_PACKAGE_MESSAGE_DETAILS_Python:INTERNAL=[/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config/libpython2.7.dylib][/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7][Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages][v()]
//Details about finding assimp
FIND_PACKAGE_MESSAGE_DETAILS_assimp:INTERNAL=[/opt/local/lib/libassimp.dylib][/opt/local/include/assimp][v()]
//Details about finding pqp
FIND_PACKAGE_MESSAGE_DETAILS_pqp:INTERNAL=[/opt/local/lib/libPQP.dylib][/opt/local/include/PQP][v()]
//ADVANCED property for variable: GCCXML
GCCXML-ADVANCED:INTERNAL=1
//ADVANCED property for variable: GTEST_INCLUDE_DIR
GTEST_INCLUDE_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: GTEST_LIBRARY
GTEST_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: GTEST_LIBRARY_DEBUG
GTEST_LIBRARY_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: GTEST_MAIN_LIBRARY
GTEST_MAIN_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: GTEST_MAIN_LIBRARY_DEBUG
GTEST_MAIN_LIBRARY_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: ODE_LIBRARY
ODE_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: OPENGL_INCLUDE_DIR
OPENGL_INCLUDE_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: OPENGL_gl_LIBRARY
OPENGL_gl_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: OPENGL_glu_LIBRARY
OPENGL_glu_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: PY_OMPL_COMPILE
PY_OMPL_COMPILE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: PY_OMPL_GENERATE
PY_OMPL_GENERATE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: RUBY_ARCH_DIR
RUBY_ARCH_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: RUBY_CONFIG_INCLUDE_DIR
RUBY_CONFIG_INCLUDE_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: RUBY_EXECUTABLE
RUBY_EXECUTABLE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: RUBY_HAS_VENDOR_RUBY
RUBY_HAS_VENDOR_RUBY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: RUBY_HDR_DIR
RUBY_HDR_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: RUBY_INCLUDE_DIR
RUBY_INCLUDE_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: RUBY_LIBRARY
RUBY_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: RUBY_POSSIBLE_LIB_DIR
RUBY_POSSIBLE_LIB_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: RUBY_RUBY_LIB_DIR
RUBY_RUBY_LIB_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: RUBY_SITEARCH_DIR
RUBY_SITEARCH_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: RUBY_SITELIB_DIR
RUBY_SITELIB_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: RUBY_VENDORARCH_DIR
RUBY_VENDORARCH_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: RUBY_VENDORLIB_DIR
RUBY_VENDORLIB_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: RUBY_VERSION_MAJOR
RUBY_VERSION_MAJOR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: RUBY_VERSION_MINOR
RUBY_VERSION_MINOR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: RUBY_VERSION_PATCH
RUBY_VERSION_PATCH-ADVANCED:INTERNAL=1
//ADVANCED property for variable: _ODE_CONFIG
_ODE_CONFIG-ADVANCED:INTERNAL=1