ompl-users — Users mailing list

Re: [ompl-users] Finite Control Space

[Gustavo G. <gus...@gm...>]

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 <is...@gm...> 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
> <gus...@gm...> 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
>> omp...@li...
>> https://lists.sourceforge.net/lists/listinfo/ompl-users
>>
>
>

[ompl-users] ompl 0.9.4 released

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

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

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

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 <
gus...@gm...> 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
> omp...@li...
> https://lists.sourceforge.net/lists/listinfo/ompl-users
>
>

[ompl-users] Finite Control Space

[Gustavo G. <gus...@gm...>]

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

[Gustavo G. <gus...@gm...>]

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

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

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

[Gustavo G. <gus...@gm...>]

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

Re: [ompl-users] defining goals in python

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

Tom,

Are you sure you need a new Goal-derived class? There are already 5 Goal-derived classes. The “tol” argument suggests that perhaps you misunderstood the meaning of this argument. It’s not an input tolerance, but, rather, an output value containing the distance to the goal. Maybe GoalRegion::setThreshold [1] is what you’re looking for.

[1] http://ompl.kavrakilab.org/classompl_1_1base_1_1GoalRegion.html


On Jun 6, 2011, at 3:18 PM, Tom Temple wrote:
> I'm trying to tease out how the "intermediate level" goal definitions are 
> accomplished in python.
> 
> All of the python examples use simple, singular representations of the goal. 
> I've been unable to successfully subclass the goal class in python.  My have 
> attempts have been of the form:
> 
> class MyGoal(base.Goal):
>   def __init__(self,si):
>     super(MyGoal,self).__init__(si)
> 
>   def isSatisfied(self, state, tol=.01):
>        ...
> ...
> prob = base.ProblemDefinition(si)
> goal = MyGoal(si)
> prob.setGoal(goal)
> prob.addStartState(s1)
> planner = geometric.RRT(si)
> planner.setProblemDefinition(prob)
> planner.setup()
> solved = planner.solve(10.0)
> 
> this errors with something inscrutable (to me):
> TypeError: No to_python (by-value) converter found for C++ type: double
> And this error occurs before isSatisfied gets called.
> 
> Of course it could be a bug in my code but I don't see how. I'm hoping that 
> someone can confirm that this part of the API works as expected.  Better still 
> would be to say: "You didn't look hard enough, bonehead! There is a code sample 
> right here <link/>"
> 
> Thanks, all
> 
> -- 
> Tom Temple, PhD.
> Scientist
> tom...@ve...
> 617-674-8544 (office)
> 617-833-5130 (mobile)
> www.vecna.com
> 
> Cambridge Research Laboratory
> Vecna Technologies, Inc.
> 36 Cambridge Park Drive
> Cambridge, MA 02140
> Office: (617) 864-0636
> Fax: (617) 864-0638
> 
> Better Technology, Better World (TM)
> 
> 
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> ompl-users mailing list
> omp...@li...
> https://lists.sourceforge.net/lists/listinfo/ompl-users
> 

-- 
Mark Moll

[ompl-users] defining goals in python

[Tom T. <tom...@ve...>]

I'm trying to tease out how the "intermediate level" goal definitions are 
accomplished in python.

All of the python examples use simple, singular representations of the goal. 
I've been unable to successfully subclass the goal class in python.  My have 
attempts have been of the form:

class MyGoal(base.Goal):
   def __init__(self,si):
     super(MyGoal,self).__init__(si)

   def isSatisfied(self, state, tol=.01):
        ...
...
prob = base.ProblemDefinition(si)
goal = MyGoal(si)
prob.setGoal(goal)
prob.addStartState(s1)
planner = geometric.RRT(si)
planner.setProblemDefinition(prob)
planner.setup()
solved = planner.solve(10.0)

this errors with something inscrutable (to me):
TypeError: No to_python (by-value) converter found for C++ type: double
And this error occurs before isSatisfied gets called.

Of course it could be a bug in my code but I don't see how. I'm hoping that 
someone can confirm that this part of the API works as expected.  Better still 
would be to say: "You didn't look hard enough, bonehead! There is a code sample 
right here <link/>"

Thanks, all

-- 
Tom Temple, PhD.
Scientist
tom...@ve...
617-674-8544 (office)
617-833-5130 (mobile)
www.vecna.com

Cambridge Research Laboratory
Vecna Technologies, Inc.
36 Cambridge Park Drive
Cambridge, MA 02140
Office: (617) 864-0636
Fax: (617) 864-0638

Better Technology, Better World (TM)

Re: [ompl-users] OMPL GUI + Articulated robots

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

Hi Lin Loi,

The OMPL library is compiled into binary python modules that need to be imported at runtime whenever you use the GUI (or any python program that uses OMPL). The binary modules are linked against libompl.dll and libomplapp.dll. On Linux and OS X there is some dynamic library weirdness that requires us to import libompl.dll first before any of the binary modules are imported. Perhaps this is not necessary on Windows. See if commenting out the calls to dll_loader fixes it. If that doesn’t work, perhaps Windows can’t find the dll’s. To test if that is the case, can you try adding the path where the ompl dll’s are located to the Windows’s System PATH environment variable?


On May 19, 2011, at 11:56 PM, Lin Loi wrote:

> Hi Mark
> 
> If I can manage to get the GUI to work under windows I will definitely try to write down how I did. Currently the GUI have some import errors. It cannot find some files:
> 
> C:\Python27>python C:\Users\user\Downloads\omplapp-0.9.3-Source\omplapp-0.9.3-So
> urce\gui\ompl_app.py
> Traceback (most recent call last):
>   File "C:\Users\user\Downloads\omplapp-0.9.3-Source\omplapp-0.9.3-Source\gui\om
> pl_app.py", line 40, in <module>
>     from ompl.util import OutputHandler, useOutputHandler
>   File "C:\Users\user\Downloads\omplapp-0.9.3-Source\omplapp-0.9.3-Source\ompl/p
> y-bindings\ompl\util\__init__.py", line 3, in <module>
>     dll_loader('ompl', dirname(abspath(__file__)))
>   File "C:\Users\user\Downloads\omplapp-0.9.3-Source\omplapp-0.9.3-Source\ompl/p
> y-bindings\ompl\__init__.py", line 27, in dll_loader
>     raise ImportError
> ImportError
> 
> I am not python expert. I will dig deeper into this. If you have any idea of how i solve this, please comment
> 
> Thanks.
> 
> 2011/5/19 Mark Moll <mm...@ri...>
> 
> On May 19, 2011, at 12:06 AM, Lin Loi wrote:
> 
> > Hi Mark and thanks for answering.
> >
> > 2011/5/18 Mark Moll <mm...@ri...>
> >
> > On May 18, 2011, at 12:45 AM, Lin Loi wrote:
> > > I have built the OMPL library successfully (generated a ompl.lib file) and can run the RigidBodyPlanning.cpp code sucessfully (found solution) in a console project in VS 2008 by linking to the ompl.lib file. The problem is that I do not know how to get the GUI working. Do I need to build something separately because I cannot see any exe file in the project folders to run?
> >
> > The GUI is built as an extra layer on top of OMPL. The basic distribution of OMPL doesn’t include it. You need to download omplapp from http://ompl.kavrakilab.org/download.html. The GUI is written in python and doesn’t need to be compiled. However, it does have a fair number of dependencies that might be more difficult to install on Windows than Linux or OS X. See http://ompl.kavrakilab.org/installation.html for details.
> >
> > Yeah. there were quite a lot of dependencies, but I somehow managed to fix it.
> > I managed to build OMPL_app project succesfully, but I still cannot run anyt GUI. The only output from the build is a ompl_app.dll file. How should I do?
> 
> 
> It’s great you managed to build everything under MS Windows. Please send any tips for building OMPL.app on Windows. We can add this to the installation instructions (of course, you’ll be acknowledged).
> 
> The GUI still needs to be launched from the command line. On MS Windows I think you need to start cmd.exe and then type “python C:\omplapp\gui\ompl_app.py” (or wherever you have ompl_app.py on your machine). There are some programs to turn a python script into an app that you can launch from, say, your desktop (py2exe on MS Windows, py2app on OS X), but we are reluctant to add even more dependencies to OMPL.app (esp. since there are many other demo programs that come with OMPL.app and OMPL that need to be run from the command line anyway).
> 
> >  > I built the project under windows 7 with VS 2008.
> > >
> > > Also regarding articulated robots. I am interested in using OMPL for high DoF (6+) robots. How do I do this? Do I need to tell OMPL how to generate the high-DoF states (configurations in C-space) or is it anything more that I will need to do?
> >
> > The easiest way is to create a CompoundStatemanifold and add the appropriate submanifolds. See http://ompl.kavrakilab.org/workingWithStates.html. You will also need to write a state validity checker. See http://ompl.kavrakilab.org/stateValidation.html.
> >
> >
> > --
> > Mark Moll
> >
> >
> >
> >
> 
> --
> Mark Moll
> 
> 
> 
> 

-- 
Mark Moll

[ompl-users] OMPL changes

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

Dear all,

This e-mail is to notify you that in view of upcoming state space  
implementations we have renamed the StateManifold class to StateSpace and  
the ControlManifold class to ControlSpace. The reason for this change is  
that in future versions the included state spaces will not necessarily be  
manifolds; in fact, the state space does not need to be a manifold in all  
planning scenarios.
The change starts in the default branch at revision 990 and will be  
included in our next release.
If you have any comments / suggestions / concerns, please let us know.

Best regards,
Ioan Sucan

Re: [ompl-users] OMPL GUI + Articulated robots

[Lin L. <lin...@gm...>]

Hi Mark

If I can manage to get the GUI to work under windows I will definitely try
to write down how I did. Currently the GUI have some import errors. It
cannot find some files:

C:\Python27>python
C:\Users\user\Downloads\omplapp-0.9.3-Source\omplapp-0.9.3-So
urce\gui\ompl_app.py
Traceback (most recent call last):
  File
"C:\Users\user\Downloads\omplapp-0.9.3-Source\omplapp-0.9.3-Source\gui\om
pl_app.py", line 40, in <module>
    from ompl.util import OutputHandler, useOutputHandler
  File
"C:\Users\user\Downloads\omplapp-0.9.3-Source\omplapp-0.9.3-Source\ompl/p
y-bindings\ompl\util\__init__.py", line 3, in <module>
    dll_loader('ompl', dirname(abspath(__file__)))
  File
"C:\Users\user\Downloads\omplapp-0.9.3-Source\omplapp-0.9.3-Source\ompl/p
y-bindings\ompl\__init__.py", line 27, in dll_loader
    raise ImportError
ImportError

I am not python expert. I will dig deeper into this. If you have any idea of
how i solve this, please comment

Thanks.

2011/5/19 Mark Moll <mm...@ri...>

>
> On May 19, 2011, at 12:06 AM, Lin Loi wrote:
>
> > Hi Mark and thanks for answering.
> >
> > 2011/5/18 Mark Moll <mm...@ri...>
> >
> > On May 18, 2011, at 12:45 AM, Lin Loi wrote:
> > > I have built the OMPL library successfully (generated a ompl.lib file)
> and can run the RigidBodyPlanning.cpp code sucessfully (found solution) in a
> console project in VS 2008 by linking to the ompl.lib file. The problem is
> that I do not know how to get the GUI working. Do I need to build something
> separately because I cannot see any exe file in the project folders to run?
> >
> > The GUI is built as an extra layer on top of OMPL. The basic distribution
> of OMPL doesn’t include it. You need to download omplapp from
> http://ompl.kavrakilab.org/download.html. The GUI is written in python and
> doesn’t need to be compiled. However, it does have a fair number of
> dependencies that might be more difficult to install on Windows than Linux
> or OS X. See http://ompl.kavrakilab.org/installation.html for details.
> >
> > Yeah. there were quite a lot of dependencies, but I somehow managed to
> fix it.
> > I managed to build OMPL_app project succesfully, but I still cannot run
> anyt GUI. The only output from the build is a ompl_app.dll file. How should
> I do?
>
>
> It’s great you managed to build everything under MS Windows. Please send
> any tips for building OMPL.app on Windows. We can add this to the
> installation instructions (of course, you’ll be acknowledged).
>
> The GUI still needs to be launched from the command line. On MS Windows I
> think you need to start cmd.exe and then type “python
> C:\omplapp\gui\ompl_app.py” (or wherever you have ompl_app.py on your
> machine). There are some programs to turn a python script into an app that
> you can launch from, say, your desktop (py2exe on MS Windows, py2app on OS
> X), but we are reluctant to add even more dependencies to OMPL.app (esp.
> since there are many other demo programs that come with OMPL.app and OMPL
> that need to be run from the command line anyway).
>
> >  > I built the project under windows 7 with VS 2008.
> > >
> > > Also regarding articulated robots. I am interested in using OMPL for
> high DoF (6+) robots. How do I do this? Do I need to tell OMPL how to
> generate the high-DoF states (configurations in C-space) or is it anything
> more that I will need to do?
> >
> > The easiest way is to create a CompoundStatemanifold and add the
> appropriate submanifolds. See
> http://ompl.kavrakilab.org/workingWithStates.html. You will also need to
> write a state validity checker. See
> http://ompl.kavrakilab.org/stateValidation.html.
> >
> >
> > --
> > Mark Moll
> >
> >
> >
> >
>
> --
> Mark Moll
>
>
>
>

Re: [ompl-users] OMPL GUI + Articulated robots

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

On May 19, 2011, at 12:06 AM, Lin Loi wrote:

> Hi Mark and thanks for answering.
> 
> 2011/5/18 Mark Moll <mm...@ri...>
> 
> On May 18, 2011, at 12:45 AM, Lin Loi wrote:
> > I have built the OMPL library successfully (generated a ompl.lib file) and can run the RigidBodyPlanning.cpp code sucessfully (found solution) in a console project in VS 2008 by linking to the ompl.lib file. The problem is that I do not know how to get the GUI working. Do I need to build something separately because I cannot see any exe file in the project folders to run?
> 
> The GUI is built as an extra layer on top of OMPL. The basic distribution of OMPL doesn’t include it. You need to download omplapp from http://ompl.kavrakilab.org/download.html. The GUI is written in python and doesn’t need to be compiled. However, it does have a fair number of dependencies that might be more difficult to install on Windows than Linux or OS X. See http://ompl.kavrakilab.org/installation.html for details.
> 
> Yeah. there were quite a lot of dependencies, but I somehow managed to fix it.
> I managed to build OMPL_app project succesfully, but I still cannot run anyt GUI. The only output from the build is a ompl_app.dll file. How should I do?


It’s great you managed to build everything under MS Windows. Please send any tips for building OMPL.app on Windows. We can add this to the installation instructions (of course, you’ll be acknowledged). 

The GUI still needs to be launched from the command line. On MS Windows I think you need to start cmd.exe and then type “python C:\omplapp\gui\ompl_app.py” (or wherever you have ompl_app.py on your machine). There are some programs to turn a python script into an app that you can launch from, say, your desktop (py2exe on MS Windows, py2app on OS X), but we are reluctant to add even more dependencies to OMPL.app (esp. since there are many other demo programs that come with OMPL.app and OMPL that need to be run from the command line anyway).

>  > I built the project under windows 7 with VS 2008.
> >
> > Also regarding articulated robots. I am interested in using OMPL for high DoF (6+) robots. How do I do this? Do I need to tell OMPL how to generate the high-DoF states (configurations in C-space) or is it anything more that I will need to do?
> 
> The easiest way is to create a CompoundStatemanifold and add the appropriate submanifolds. See http://ompl.kavrakilab.org/workingWithStates.html. You will also need to write a state validity checker. See http://ompl.kavrakilab.org/stateValidation.html.
> 
> 
> --
> Mark Moll
> 
> 
> 
> 

-- 
Mark Moll

[ompl-users] OMPL GUI + Articulated robots

[Lin L. <lin...@gm...>]

Hi.

I have built the OMPL library successfully (generated a ompl.lib file) and
can run the RigidBodyPlanning.cpp code sucessfully (found solution) in a
console project in VS 2008 by linking to the ompl.lib file. The problem is
that I do not know how to get the GUI working. Do I need to build something
separately because I cannot see any exe file in the project folders to run?

I built the project under windows 7 with VS 2008.

Also regarding articulated robots. I am interested in using OMPL for high
DoF (6+) robots. How do I do this? Do I need to tell OMPL how to generate
the high-DoF states (configurations in C-space) or is it anything more that
I will need to do?

Thanks for the help.

[ompl-users] ompl 0.9.3 released

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

We are happy to announce a new release of OMPL, version 0.9.3. This release includes the following changes:

	• Added support for visualizing internal planner data
	• In OMPL.app, we added planning for 2D environments (SE2)
	• Significant reorganization of code in OMPL.app library
	• Added path smoothing with splines
	• Added a bi-directional implementation of KPIECE (BKPIECE)
	• Support for computation of clearance and gradients that move away from invalid regions
	• Separate "magic constants" to a separate, visible, location
	• A number of bug fixes

Point your browser to http://ompl.kavrakilab.org/download.html to download the latest version.

-- 
Mark Moll

Re: [ompl-users] path constraints & strange arm movement

[Sachin C. <sa...@wi...>]

Hi Nic,

Here are some answers to your questions:

1. For path constraints, as Ioan mentioned, the planners can take
quite a while to converge. An alternative that you can use, depending
on the geometry of your arm, is to plan in workspace coordinates and
use inverse kinematics. We do that with the PR2 by planning in the
end-effector cartesian degrees of freedom + the redundancy and it
works pretty well. The advantage of planning in this space is that
orientation constraints can be easily represented here. You can see
how this planner is configured by checking this configuration file:
pr2_arm_navigation_planning/config/ompl_planning.yaml. The file
contains configuration for "right_arm_cartesian" and
"left_arm_cartesian" planners which plan in end-effector + redundancy
space for the PR2 arms. You can address these planners directly in
that space - i.e. you can provide goals in end-effector+redundancy
space.

2. For path smoothing, you can use the trajectory filters we have
setup in ROS. They basically use a random short-cutting with cubic
splines. The configuration for these filters is setup in
pr2_arm_navigation_filtering. They should reduce the amount of such
"randomized" motions that you see from the arms.

Please note that some of these components are not well-documented yet
but we are making a big effort to add more documentation and
tutorials.

Hope this helps,

Best Regards,
Sachin


On Thu, Apr 28, 2011 at 7:08 AM,  <is...@gm...> wrote:
> Hello Nic,
>
> I am cc'ing Sachin Chitta (from Willow Garage), in case he has additional
> comments. Responses are inline.
>
> On Apr 28, 2011 7:20am, "Dirkx, N.J." <n.j...@st...> wrote:
>> Hi there
>> ,
>>
>>
>> I am using OMPL planners for a 7DOF robotic arm (non-pr2) with ROS. More
>> specific, I have set it up according to the pr2_arm_navigation stack, so I
>> am using the move_arm node and the ompl_ros_interface.
>>
>>
>>
>> The entire chain from perception to execution is working, I only ran into
>> two problems:
>>
>>
>>
>> 1.Path constraints:
>>
>>        As soon as I add path constraints on the orientation of the end
>> effector the planners fail to find a path. It doesn't matter which planner I
>> choose, they all show the same behaviour. Even if the      constraints are
>> set really large (say 2.5 rad), they don't succeed in finding a solution.
>>
>>        The following code snippet shows how I added the path constraints:
>>
>>
>>
>> //set path constraints
>>
>>
>>  goalB.motion_plan_request.path_constraints.orientation_constraints.resize(1);
>>
>>
>>  goalB.motion_plan_request.path_constraints.orientation_constraints[0].header.frame_id
>> = "base_link";
>>
>>
>>  goalB.motion_plan_request.path_constraints.orientation_constraints[0].header.stamp
>> = ros::Time::now();
>>
>>
>>  goalB.motion_plan_request.path_constraints.orientation_constraints[0].link_name
>> = "hand_right";
>>
>>
>>
>>  geometry_msgs::Quaternion quat_msg =
>> tf::createQuaternionMsgFromRollPitchYaw(0.0, 0.0, 0.0);
>>
>>
>>
>>
>>  goalB.motion_plan_request.path_constraints.orientation_constraints[0].orientation.x
>> = quat_msg.x;
>>
>>
>>  goalB.motion_plan_request.path_constraints.orientation_constraints[0].orientation.y
>> = quat_msg.y;
>>
>>
>>  goalB.motion_plan_request.path_constraints.orientation_constraints[0].orientation.z
>> = quat_msg.z;
>>
>>
>>  goalB.motion_plan_request.path_constraints.orientation_constraints[0].orientation.w
>> = quat_msg.w;
>>
>>
>>
>>
>>  goalB.motion_plan_request.path_constraints.orientation_constraints[0].type
>> = motion_planning_msgs::OrientationConstraint::HEADER_FRAME;
>>
>>
>>  goalB.motion_plan_request.path_constraints.orientation_constraints[0].absolute_roll_tolerance
>> = 1.5;
>>
>>
>>  goalB.motion_plan_request.path_constraints.orientation_constraints[0].absolute_pitch_tolerance
>> = 1.5;
>>
>>
>>  goalB.motion_plan_request.path_constraints.orientation_constraints[0].absolute_yaw_tolerance
>> = 1.5;
>>
>>
>>
>>        My question are:
>>
>>        Is this the right way to give in path constraints?
>
> To me it seems the setup is correct, but it has changed a bit since I last
> used it. Perhaps Sachin can comment if there is something wrong.
>
> From the behaviour you describe for the planners, it sounds like they are
> unable to find valid states. Do you by any chance have ros::console
> information from OMPL? It should appear in your log and should say things
> like "No solution found after ... seconds" and
> ".... created ... states". I'm curious about the number of states created by
> the planners. If this is low (under 10) it means there is something wrong
> with the evaluation of validity, and perhaps in your input.
>
>
>>
>>        To what extent can the planners deal with path constraints?
>>
>
> The planners rely on sampling the state space. If a constraint will reduce
> the volume of the valid space to 0 within the 7-dimensional state space for
> the robot, the methods currently employed by the planners will not work. If
> you keep the volume above 0, the probability of finding a solution is
> proportional to the ratio of the valid volume with respect to the total
> volume.
>
>>        Is there a planner that is recommended if I want to use path
>> constraints?
>>
> It really depends on the problem you are solving. I don't think I can say
> this with certainty. I would avoid lazy planners perhaps. So... if SBL or
> LBKPIECE1 or LazyRRT appear to be slower, they probably will be consistently
> slower.
> My top choices would be KPIECE1 and RRTConnect. OMPL just got a new planner
> (BKPIECE1), which I think will soon be available through ROS as well. That
> will perhaps be a good choice as well.
>
>>
>>
>>
>>
>> 2.Large/strange arm movement
>>
>>       The planned planned path to the end pose very seems to be very
>> indirect/ inefficient. The arm moves through a large part of the joint space
>> before ending up on the right spot, resulting in very exotic arm movements.
>> All planners show similar behaviour.
>>
> This is due to the randomized nature of the algorithms. Adding constraints
> typically makes matters worse, from this point of view :(
>
>>       Is there a way to suppress these movements or to punish joint states
>> that have a large distance to, say, the ideal path?
>>
> We just added some smoothing code in OMPL, but it is not yet part of ROS.
> This will still not give you an optimal path, but it should produce more
> natural looking paths.
>
>
> Ioan
>
>>
>>
>> Thanks
>>
>>
>>
>> Nic
>>
>>
>> ------------------------------------------------------------------------------
>>
>> WhatsUp Gold - Download Free Network Management Software
>>
>> The most intuitive, comprehensive, and cost-effective network
>>
>> management toolset available today.  Delivers lowest initial
>>
>> acquisition cost and overall TCO of any competing solution.
>>
>> http://p.sf.net/sfu/whatsupgold-sd
>>
>> _______________________________________________
>>
>> ompl-users mailing list
>>
>> omp...@li...
>>
>> https://lists.sourceforge.net/lists/listinfo/ompl-users
>>
>>



-- 
Sachin Chitta
Research Scientist
Willow Garage

Re: [ompl-users] path constraints & strange arm movement

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

Hello Nic,

I am cc'ing Sachin Chitta (from Willow Garage), in case he has additional  
comments. Responses are inline.

On Apr 28, 2011 7:20am, "Dirkx, NJ" <nj...@st...> wrote:
> Hi there
> ,


> I am using OMPL planners for a 7DOF robotic arm (non-pr2) with ROS. More  
> specific, I have set it up according to the pr2_arm_navigation stack, so  
> I am using the move_arm node and the ompl_ros_interface.



> The entire chain from perception to execution is working, I only ran into  
> two problems:



> 1.Path constraints:

> As soon as I add path constraints on the orientation of the end effector  
> the planners fail to find a path. It doesn't matter which planner I  
> choose, they all show the same behaviour. Even if the constraints are set  
> really large (say 2.5 rad), they don't succeed in finding a solution.

> The following code snippet shows how I added the path constraints:



> //set path constraints

> goalB.motion_plan_request.path_constraints.orientation_constraints.resize(1);

> goalB.motion_plan_request.path_constraints.orientation_constraints[0].header.frame_id  
> = "base_link";

> goalB.motion_plan_request.path_constraints.orientation_constraints[0].header.stamp  
> =  
> ros::Time::now();

> goalB.motion_plan_request.path_constraints.orientation_constraints[0].link_name  
> = "hand_right";



> geometry_msgs::Quaternion quat_msg =  
> tf::createQuaternionMsgFromRollPitchYaw(0.0, 0.0, 0.0);



> goalB.motion_plan_request.path_constraints.orientation_constraints[0].orientation.x  
> =  
> quat_msg.x;

> goalB.motion_plan_request.path_constraints.orientation_constraints[0].orientation.y  
> =  
> quat_msg.y;

> goalB.motion_plan_request.path_constraints.orientation_constraints[0].orientation.z  
> =  
> quat_msg.z;

> goalB.motion_plan_request.path_constraints.orientation_constraints[0].orientation.w  
> =  
> quat_msg.w;



> goalB.motion_plan_request.path_constraints.orientation_constraints[0].type  
> =  
> motion_planning_msgs::OrientationConstraint::HEADER_FRAME;

> goalB.motion_plan_request.path_constraints.orientation_constraints[0].absolute_roll_tolerance  
> =  
> 1.5;

> goalB.motion_plan_request.path_constraints.orientation_constraints[0].absolute_pitch_tolerance  
> =  
> 1.5;

> goalB.motion_plan_request.path_constraints.orientation_constraints[0].absolute_yaw_tolerance  
> =  
> 1.5;



> My question are:

> Is this the right way to give in path constraints?

To me it seems the setup is correct, but it has changed a bit since I last  
used it. Perhaps Sachin can comment if there is something wrong.

 From the behaviour you describe for the planners, it sounds like they are  
unable to find valid states. Do you by any chance have ros::console  
information from OMPL? It should appear in your log and should say things  
like "No solution found after ... seconds" and
".... created ... states". I'm curious about the number of states created  
by the planners. If this is low (under 10) it means there is something  
wrong with the evaluation of validity, and perhaps in your input.



> To what extent can the planners deal with path constraints?


The planners rely on sampling the state space. If a constraint will reduce  
the volume of the valid space to 0 within the 7-dimensional state space for  
the robot, the methods currently employed by the planners will not work. If  
you keep the volume above 0, the probability of finding a solution is  
proportional to the ratio of the valid volume with respect to the total  
volume.

> Is there a planner that is recommended if I want to use path constraints?

It really depends on the problem you are solving. I don't think I can say  
this with certainty. I would avoid lazy planners perhaps. So... if SBL or  
LBKPIECE1 or LazyRRT appear to be slower, they probably will be  
consistently slower.
My top choices would be KPIECE1 and RRTConnect. OMPL just got a new planner  
(BKPIECE1), which I think will soon be available through ROS as well. That  
will perhaps be a good choice as well.





> 2.Large/strange arm movement

> The planned planned path to the end pose very seems to be very indirect/  
> inefficient. The arm moves through a large part of the joint space before  
> ending up on the right spot, resulting in very exotic arm movements. All  
> planners show similar behaviour.

This is due to the randomized nature of the algorithms. Adding constraints  
typically makes matters worse, from this point of view :(

> Is there a way to suppress these movements or to punish joint states that  
> have a large distance to, say, the ideal path?

We just added some smoothing code in OMPL, but it is not yet part of ROS.  
This will still not give you an optimal path, but it should produce more  
natural looking paths.


Ioan



> Thanks



> Nic

> ------------------------------------------------------------------------------

> WhatsUp Gold - Download Free Network Management Software

> The most intuitive, comprehensive, and cost-effective network

> management toolset available today. Delivers lowest initial

> acquisition cost and overall TCO of any competing solution.

> http://p.sf.net/sfu/whatsupgold-sd

> _______________________________________________

> ompl-users mailing list

> omp...@li...

> https://lists.sourceforge.net/lists/listinfo/ompl-users

[ompl-users] path constraints & strange arm movement

[Dirkx, N.J. <n.j...@st...>]

Hi there

I am using OMPL planners for a 7DOF robotic arm (non-pr2) with ROS. More specific, I have set it up according to the pr2_arm_navigation stack, so I am using the move_arm node and the ompl_ros_interface. 

The entire chain from perception to execution is working, I only ran into two problems:

1.Path constraints:
	As soon as I add path constraints on the orientation of the end effector the planners fail to find a path. It doesn't matter which planner I choose, they all show the same behaviour. Even if the 	constraints are set really large (say 2.5 rad), they don't succeed in finding a solution. 
	The following code snippet shows how I added the path constraints:

//set path constraints
  goalB.motion_plan_request.path_constraints.orientation_constraints.resize(1);
  goalB.motion_plan_request.path_constraints.orientation_constraints[0].header.frame_id = "base_link";
  goalB.motion_plan_request.path_constraints.orientation_constraints[0].header.stamp = ros::Time::now();
  goalB.motion_plan_request.path_constraints.orientation_constraints[0].link_name = "hand_right";
   
  geometry_msgs::Quaternion quat_msg = tf::createQuaternionMsgFromRollPitchYaw(0.0, 0.0, 0.0);
   
  goalB.motion_plan_request.path_constraints.orientation_constraints[0].orientation.x = quat_msg.x;
  goalB.motion_plan_request.path_constraints.orientation_constraints[0].orientation.y = quat_msg.y;
  goalB.motion_plan_request.path_constraints.orientation_constraints[0].orientation.z = quat_msg.z;
  goalB.motion_plan_request.path_constraints.orientation_constraints[0].orientation.w = quat_msg.w;

  goalB.motion_plan_request.path_constraints.orientation_constraints[0].type = motion_planning_msgs::OrientationConstraint::HEADER_FRAME;
  goalB.motion_plan_request.path_constraints.orientation_constraints[0].absolute_roll_tolerance = 1.5;
  goalB.motion_plan_request.path_constraints.orientation_constraints[0].absolute_pitch_tolerance = 1.5;
  goalB.motion_plan_request.path_constraints.orientation_constraints[0].absolute_yaw_tolerance = 1.5;

	My question are: 
	Is this the right way to give in path constraints?
	To what extent can the planners deal with path constraints?
	Is there a planner that is recommended if I want to use path constraints?
		

2.Large/strange arm movement
       The planned planned path to the end pose very seems to be very indirect/ inefficient. The arm moves through a large part of the joint space before ending up on the right spot, resulting in very exotic arm movements. All planners show similar behaviour.
       Is there a way to suppress these movements or to punish joint states that have a large distance to, say, the ideal path?

Thanks

Nic

Re: [ompl-users] Version information in libompl

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

Rich,

On Apr 23, 2011, at 11:36 PM, Rich Mattes wrote:
> I'm working on packaging ompl for Fedora[1], and it looks like there's 
> no versioning information built into the libompl.so library.  The 
> version information in question is specified by the VERSION and 
> SOVERSION properties for the library, is there any reason why these are 
> omitted?

Thanks for bringing this to our attention. It has been fixed in our repository and should appear in the 0.9.3 release, which is expected to be released in the next couple of months.

BTW, we use CPack (http://www.cmake.org/Wiki/CMake:CPackPackageGenerators) for creating source tar balls. If you’d like to contribute a patch with RPM settings, we’d be happy to include it. In case you’re not familiar with cpack, it allows you to build source and binary packages in rpm format and a number of other formats.

> 
> Thanks,
> 
> Rich Mattes
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=690038

-- 
Mark Moll

[ompl-users] Version information in libompl

[Rich M. <ric...@gm...>]

Hi,

I'm working on packaging ompl for Fedora[1], and it looks like there's 
no versioning information built into the libompl.so library.  The 
version information in question is specified by the VERSION and 
SOVERSION properties for the library, is there any reason why these are 
omitted?

Thanks,

Rich Mattes

[1] https://bugzilla.redhat.com/show_bug.cgi?id=690038

Re: [ompl-users] Behavior of planners in changing environments

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

Boris,

We realize that replanning is important for many people. One of our collaborators is currently working on adding replanning as a high-level layer to OMPL. Within the next couple of months we should have an initial version.

On Apr 5, 2011, at 9:49 AM, Ioan Alexandru Sucan wrote:

> Boris,
> 
> Currently none of the planners in ompl account for changes in the validity of a state in between calls to solve(). This means you will have to call clear() as you suggest and plan from scratch.
> 
> Ioan
> 
> 
>> On Tue, Apr 5, 2011 at 7:00 AM, Boris Lau <la...@in...> wrote:
>> Hello,
>> 
>> are there any planners in the ompl library that can handle changes in
>> the environment (location obstacles)? Or do I have to call clear() and
>> let them plan from scratch after such changes?

-- 
Mark Moll

Re: [ompl-users] Behavior of planners in changing environments

[Boris L. <la...@in...>]

Ioan,
thanks for your quick reply!
Boris

On 04/05/2011 04:49 PM, Ioan Alexandru Sucan wrote:
> Boris,
>
> Currently none of the planners in ompl account for changes in the
> validity of a state in between calls to solve(). This means you will
> have to call clear() as you suggest and plan from scratch.
>
> Ioan
>
>
> On Tue, Apr 5, 2011 at 7:00 AM, Boris Lau
> <la...@in... <mailto:la...@in...>>
> wrote:
>
>     Hello,
>
>     are there any planners in the ompl library that can handle changes in
>     the environment (location obstacles)? Or do I have to call clear() and
>     let them plan from scratch after such changes?
>
>     Best, Boris
>
>     --
>     Boris Lau
>
>     Albert-Ludwigs-University Freiburg
>     Institute of Computer Science, Autonomous Intelligent Systems Group
>     Georges-Koehler-Allee 079, D-79110 Freiburg, Germany
>
>     Building 079, Room 1005
>     Phone: +49 761 203-8012 <tel:%2B49%20761%20203-8012> | Mobile: +49
>     174 9436758 <tel:%2B49%20174%209436758>
>     http://www.informatik.uni-freiburg.de/~lau
>     <http://www.informatik.uni-freiburg.de/%7Elau>
>
>     ------------------------------------------------------------------------------
>     Xperia(TM) PLAY
>     It's a major breakthrough. An authentic gaming
>     smartphone on the nation's most reliable network.
>     And it wants your games.
>     http://p.sf.net/sfu/verizon-sfdev
>     _______________________________________________
>     ompl-users mailing list
>     omp...@li...
>     <mailto:omp...@li...>
>     https://lists.sourceforge.net/lists/listinfo/ompl-users
>
>


-- 
Boris Lau

Albert-Ludwigs-University Freiburg
Institute of Computer Science, Autonomous Intelligent Systems Group
Georges-Koehler-Allee 079, D-79110 Freiburg, Germany

Building 079, Room 1005
Phone: +49 761 203-8012 | Mobile: +49 174 9436758
http://www.informatik.uni-freiburg.de/~lau

Re: [ompl-users] Behavior of planners in changing environments

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

Boris,

Currently none of the planners in ompl account for changes in the validity
of a state in between calls to solve(). This means you will have to call
clear() as you suggest and plan from scratch.

Ioan


On Tue, Apr 5, 2011 at 7:00 AM, Boris Lau <la...@in...>wrote:

> Hello,
>
> are there any planners in the ompl library that can handle changes in
> the environment (location obstacles)? Or do I have to call clear() and
> let them plan from scratch after such changes?
>
> Best, Boris
>
> --
> Boris Lau
>
> Albert-Ludwigs-University Freiburg
> Institute of Computer Science, Autonomous Intelligent Systems Group
> Georges-Koehler-Allee 079, D-79110 Freiburg, Germany
>
> Building 079, Room 1005
> Phone: +49 761 203-8012 | Mobile: +49 174 9436758
> http://www.informatik.uni-freiburg.de/~lau
>
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> ompl-users mailing list
> omp...@li...
> https://lists.sourceforge.net/lists/listinfo/ompl-users
>

[ompl-users] Behavior of planners in changing environments

[Boris L. <la...@in...>]

Hello,

are there any planners in the ompl library that can handle changes in 
the environment (location obstacles)? Or do I have to call clear() and 
let them plan from scratch after such changes?

Best, Boris

-- 
Boris Lau

Albert-Ludwigs-University Freiburg
Institute of Computer Science, Autonomous Intelligent Systems Group
Georges-Koehler-Allee 079, D-79110 Freiburg, Germany

Building 079, Room 1005
Phone: +49 761 203-8012 | Mobile: +49 174 9436758
http://www.informatik.uni-freiburg.de/~lau

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

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

addin CC:


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

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

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

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

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

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

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

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

> Ioan

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