ompl-users — Users mailing list

[ompl-users] Control Planner ---RRT.cpp

[Rajaneesh <raj...@gm...>]

Hello,

 This is with regards to the control planner. For control planner, we
specify minimum and maximum control duration. Referring to RRT.cpp under
ompl.control.planner.rrt.src, It has check for minimum control duration
below. Could not find the check for maxcontrolduration

 if (cd >= siC_->getMinControlDuration())

1. My first question is Is maximum control duration optional?

Further referring to propagateWhileValid(....) from the
SpaceInformation.cpp in ompl.base.src, my interpretation is that it
populates intermediate "pstates" from nearest neighbourhood to a chosen
random points (PRand), with a randomly selected control and random control
steps that is greater than minimum control duration.

2. My second question is that will random control necessarily lead to
proximity to chosen random points (PRand) or should it be the other way
round (Given PRand, find control that satisfies it)

Regards
Rajaneesh

[ompl-users] Control Bounds

[Rajaneesh <raj...@gm...>]

Hello,

I have specified the control bound as

        cbounds = ob.RealVectorBounds(2)
        cbounds.setLow(0,0)
        cbounds.setLow(1,-0.1)
        cbounds.setHigh(0, 10)
        cbounds.setHigh(1, .1)

and have reused the propagator as in the demo

        state.setX(start.getX() + control[0] * duration *
cos(start.getYaw()))
        state.setY(start.getY() + control[0] * duration *
sin(start.getYaw()))
        state.setYaw(start.getYaw() + control[1] * duration)


>From the control bounds specified, We have the velocity as 0<v<10 and theta
-.1<theta<.1 .. I expect my vehicle to be unidirectional and the results
also confirm it. However
ss.getSpaceInformation().canPropagateBackward() returns a true value. Am I
missing on something here.

Regards
Rajaneesh

Re: [ompl-users] Collision Checker PQP exception

[Rajaneesh <raj...@gm...>]

Hello,

I installed PQP and ran the make update_bindings. I am getting the
following message. Also CMakeCache states that PQP include  directory not
found. But library directory is identified. Can you please suggest to me if
I am missing on any Makefile Setup? Or should I ignore these messages and
proceed.



While running make update_bindings

The following OPTIONAL packages have not been found:

 * pypy, <http://pypy.org>
   Used to speed up the generation of python bindings.
 * Triangle, <http://www.cs.cmu.edu/~quake/triangle.html>
   Used to create triangular decompositions of polygonal 2D environments.
 * spot, <http://spot.lrde.epita.fr>
   Used for constructing finite automata from LTL formulae.
 * MORSE, <https://www.openrobots.org/wiki/morse>
   OMPL includes a plugin for the MORSE Robot Simulation engine.
 * Drawstuff, <http://ode.org>
   Part of the ODE source distribution, used in one demo program.
 * PQP, <http://gamma.cs.unc.edu/SSV/>
   Used as an alternative, additional collision checking library (the
default is FCL).
 * Doxygen, <http://doxygen.org>
   Used to create the OMPL documentation (i.e., http://ompl.kavrakilab.org).





>From CMakeCache.txt

//Location of PQP proximity query header files
PQP_INCLUDE_DIR:PATH=PQP_INCLUDE_DIR-NOTFOUND

//Location of PQP proximity query library
PQP_LIBRARY:FILEPATH=/usr/local/lib/libPQP.a


Regards
Rajaneesh

On Wed, Jul 18, 2018 at 8:31 PM, Rajaneesh <raj...@gm...>
wrote:

> Thank you Mark... I saw bits of code in OMPL (<1.4.0) regarding PQP in
> RigidBodyGeometry as below. Just was curious to try it out and see which
> one is faster. Wanted to check if benchmark can be run for RRT with PQP and
> compare it with RRT with FCL. In my understanding collision check is one of
> the operation that consumes time.
>
>
> Code Snippet below..
>
> case PQP:
>             if (mtype_ == Motion_2D)
>                 validitySvc_ = std::make_shared<PQPStateValidityChecker<Motion_2D>>(si,
> geom, se, selfCollision);
>             else
>                 validitySvc_ = std::make_shared<PQPStateValidityChecker<Motion_3D>>(si,
> geom, se, selfCollision);
>             break;
>
>
> Regards
> Rajaneesh
>
> On Wed, Jul 18, 2018 at 7:27 PM, Mark Moll <mm...@ri...> wrote:
>
>> PQP is an optional dependency detected at build time. After you download
>> and install PQP, you will have to rebuild OMPLapp.
>>
>> Generally, FCL is now the preferred collision checker. Is there any
>> particular reason you prefer PQP over FCL?
>>
>> Mark
>>
>>
>>
>> On Jul 18, 2018, at 6:43 AM, Rajaneesh <raj...@gm...>
>> wrote:
>>
>> Hello,
>>
>>   I changed the collision checker from FCL to PQP, to check the
>> performance using the below
>> setup.setStateValidityCheckerType(setup.getCollisionCheckerType().PQP)
>>
>> setup.getCollisionCheckerType() shows that PQP has been set. But I get
>> the following exception.
>>
>> Should I download the PQP library separately?
>>
>>
>> Error:   Unexpected collision checker type (0) encountered
>>          at line 199 in /home/raj3/Downloads/omplapp-1
>> .3.2-Source/src/omplapp/geometry/RigidBodyGeometry.cpp
>>
>>
>> Also is it possible to benchmark planners for different collision check
>> algorithm like FCL and PQP using config file?
>>
>>
>>
>

Re: [ompl-users] Collision Checker PQP exception

[Rajaneesh <raj...@gm...>]

Thank you Mark... I saw bits of code in OMPL (<1.4.0) regarding PQP in
RigidBodyGeometry as below. Just was curious to try it out and see which
one is faster. Wanted to check if benchmark can be run for RRT with PQP and
compare it with RRT with FCL. In my understanding collision check is one of
the operation that consumes time.


Code Snippet below..

case PQP:
            if (mtype_ == Motion_2D)
                validitySvc_ =
std::make_shared<PQPStateValidityChecker<Motion_2D>>(si, geom, se,
selfCollision);
            else
                validitySvc_ =
std::make_shared<PQPStateValidityChecker<Motion_3D>>(si, geom, se,
selfCollision);
            break;


Regards
Rajaneesh

On Wed, Jul 18, 2018 at 7:27 PM, Mark Moll <mm...@ri...> wrote:

> PQP is an optional dependency detected at build time. After you download
> and install PQP, you will have to rebuild OMPLapp.
>
> Generally, FCL is now the preferred collision checker. Is there any
> particular reason you prefer PQP over FCL?
>
> Mark
>
>
>
> On Jul 18, 2018, at 6:43 AM, Rajaneesh <raj...@gm...>
> wrote:
>
> Hello,
>
>   I changed the collision checker from FCL to PQP, to check the
> performance using the below
> setup.setStateValidityCheckerType(setup.getCollisionCheckerType().PQP)
>
> setup.getCollisionCheckerType() shows that PQP has been set. But I get
> the following exception.
>
> Should I download the PQP library separately?
>
>
> Error:   Unexpected collision checker type (0) encountered
>          at line 199 in /home/raj3/Downloads/omplapp-
> 1.3.2-Source/src/omplapp/geometry/RigidBodyGeometry.cpp
>
>
> Also is it possible to benchmark planners for different collision check
> algorithm like FCL and PQP using config file?
>
>
>

Re: [ompl-users] Collision Checker PQP exception

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

PQP is an optional dependency detected at build time. After you download and install PQP, you will have to rebuild OMPLapp.

Generally, FCL is now the preferred collision checker. Is there any particular reason you prefer PQP over FCL?

Mark



> On Jul 18, 2018, at 6:43 AM, Rajaneesh <raj...@gm...> wrote:
> 
> Hello,
> 
>   I changed the collision checker from FCL to PQP, to check the performance using the below
> setup.setStateValidityCheckerType(setup.getCollisionCheckerType().PQP)
> 
> setup.getCollisionCheckerType() shows that PQP has been set. But I get the following exception.
> 
> Should I download the PQP library separately?
> 
> 
> Error:   Unexpected collision checker type (0) encountered
>          at line 199 in /home/raj3/Downloads/omplapp-1.3.2-Source/src/omplapp/geometry/RigidBodyGeometry.cpp
> 
> 
> Also is it possible to benchmark planners for different collision check algorithm like FCL and PQP using config file?
> 

[ompl-users] Collision Checker PQP exception

[Rajaneesh <raj...@gm...>]

Hello,

  I changed the collision checker from FCL to PQP, to check the performance
using the below
setup.setStateValidityCheckerType(setup.getCollisionCheckerType().PQP)

setup.getCollisionCheckerType() shows that PQP has been set. But I get the
following exception.

Should I download the PQP library separately?


Error:   Unexpected collision checker type (0) encountered
         at line 199 in
/home/raj3/Downloads/omplapp-1.3.2-Source/src/omplapp/geometry/RigidBodyGeometry.cpp


Also is it possible to benchmark planners for different collision check
algorithm like FCL and PQP using config file?


Regards
Rajaneesh

Re: [ompl-users] Default Nearest Neighbor search in OMPL

[Rajaneesh <raj...@gm...>]

Thank you Mark

On Tue, Jul 17, 2018 at 6:26 PM, Mark Moll <mm...@ri...> wrote:

> On Jul 17, 2018, at 6:28 AM, Rajaneesh <raj...@gm...>
> wrote:
>    Which is the default neighbor search in OMPL? Is it FLANN or KD Tree or
> GNAT or Linear Search?
>
>
> The default depends on the planning algorithm and the space the planner
> operates in:
> - If the space is a metric space and the planner is single-threaded,
>   then the default is ompl::NearestNeighborsGNATNoThreadSafety.
> - If the space is a metric space and the planner is multi-threaded,
>   then the default is ompl::NearestNeighborsGNAT.
> - If the space is a not a metric space,
>   then the default is ompl::NearestNeighborsSqrtApprox.
>
> Mark
>
>
>

Re: [ompl-users] Default Nearest Neighbor search in OMPL

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

> On Jul 17, 2018, at 6:28 AM, Rajaneesh <raj...@gm...> wrote:
>    Which is the default neighbor search in OMPL? Is it FLANN or KD Tree or GNAT or Linear Search?

The default depends on the planning algorithm and the space the planner operates in:
- If the space is a metric space and the planner is single-threaded,
  then the default is ompl::NearestNeighborsGNATNoThreadSafety.
- If the space is a metric space and the planner is multi-threaded,
  then the default is ompl::NearestNeighborsGNAT.
- If the space is a not a metric space,
  then the default is ompl::NearestNeighborsSqrtApprox.

Mark

[ompl-users] Default Nearest Neighbor search in OMPL

[Rajaneesh <raj...@gm...>]

Hello,

   Which is the default neighbor search in OMPL? Is it FLANN or KD Tree or
GNAT or Linear Search?

Regards
Rajaneesh

Re: [ompl-users] Virtual Obstacles in State Space

[Rajaneesh <raj...@gm...>]

Hello

  There are implementations of addenvironment, addrobots. Does that also
serve the purpose of adding virtual objects(environment/robots)?

Regards
Rajaneesh

On Sat, Jul 7, 2018 at 12:28 AM, Mark Moll <mm...@ri...> wrote:

> Hi Rajaneesh,
>
> Yes, you’ll have to write you own state validity checker whose isValid()
> method returns false when the robot intersects the virtual obstacles.
>
> Mark
>
>
>
> On Jul 6, 2018, at 1:39 PM, Rajaneesh <raj...@gm...>
> wrote:
>
> Hello,
>
>   Is it possible to define virtual obstacle in state space in OMPL. Though
> these obstacles are not part of current physical environment, they are
> necessarily no go areas for the robots in the state space. This is to
> formulating path using OMPL anticipating the robot or environment may be
> subjected to future modification in near future.
>
> Regards
> Rajaneesh
>
>
>

Re: [ompl-users] Objectives in OMPL path planning

[Rajaneesh <raj...@gm...>]

The objective of  minimizing the clearance is to have the robot move over
the terrain rather than fly over the terrain, as shown in the figure
attached

On Fri, Jul 13, 2018 at 4:46 PM, Rajaneesh <raj...@gm...>
wrote:

> Hello
>
> In the objectives, we have clearance objective. Is it possible to maximise
> the path length by maintaining minimum clearance. (as in Bug algorithm)
>
>
> def allocateObjective(si, objectiveType):
>     if objectiveType.lower() == "pathclearance":
>         return getClearanceObjective(si)
>     elif objectiveType.lower() == "pathlength":
>         return getPathLengthObjective(si)
>     elif objectiveType.lower() == "thresholdpathlength":
>         return getThresholdPathLengthObj(si)
>     elif objectiveType.lower() == "weightedlengthandclearancecombo":
>         return getBalancedObjective1(si)
>     else:
>         ou.OMPL_ERROR("Optimization-objective is not implemented in
> allocation function.")
>
>
>
> Regards
> Rajaneesh
>

[ompl-users] Objectives in OMPL path planning

[Rajaneesh <raj...@gm...>]

Hello

In the objectives, we have clearance objective. Is it possible to maximise
the path length by maintaining minimum clearance. (as in Bug algorithm)


def allocateObjective(si, objectiveType):
    if objectiveType.lower() == "pathclearance":
        return getClearanceObjective(si)
    elif objectiveType.lower() == "pathlength":
        return getPathLengthObjective(si)
    elif objectiveType.lower() == "thresholdpathlength":
        return getThresholdPathLengthObj(si)
    elif objectiveType.lower() == "weightedlengthandclearancecombo":
        return getBalancedObjective1(si)
    else:
        ou.OMPL_ERROR("Optimization-objective is not implemented in
allocation function.")



Regards
Rajaneesh

Re: [ompl-users] Environment mesh not rendering in OMPLAPP

[Rajaneesh <raj...@gm...>]

Hello,

Thanks.. It got resolved when I called the following method.

    def clear(self, deepClean=False):
        self.omplSetup.clear()
        self.mainWidget.glViewer.clear(deepClean)

Regards
Rajaneesh

On Thu, Jul 12, 2018 at 4:14 PM, Rajaneesh <raj...@gm...>
wrote:

> Hello,
>
> I have the following code snippet in python for loading the environment
> file and rendering it in screen. The window opens up but the
> environment.dae is not rendered. Have I missed on any initialization?
>
>
> Regards
> Rajaneesh
>
>         #In MainWindow
>         omplSetup = eval('oa.%s()' % 'GSE3RigidBodyPlanning')
>         environmentFile = join(ompl_resources_dir, 'scenario1_env.dae')
>         omplSetup.setEnvironmentMesh(environmentFile)
>         glViewer.setEnvironment(omplSetup.renderEnvironment())
>
>         ...
>         ...
>         ...
>         ...
>
>         #in PaintGL
>         if self.environment: GL.glCallList(self.environment)
>

[ompl-users] Environment mesh not rendering in OMPLAPP

[Rajaneesh <raj...@gm...>]

Hello,

I have the following code snippet in python for loading the environment
file and rendering it in screen. The window opens up but the
environment.dae is not rendered. Have I missed on any initialization?


Regards
Rajaneesh

        #In MainWindow
        omplSetup = eval('oa.%s()' % 'GSE3RigidBodyPlanning')
        environmentFile = join(ompl_resources_dir, 'scenario1_env.dae')
        omplSetup.setEnvironmentMesh(environmentFile)
        glViewer.setEnvironment(omplSetup.renderEnvironment())

        ...
        ...
        ...
        ...

        #in PaintGL
        if self.environment: GL.glCallList(self.environment)

Re: [ompl-users] Using omplSetup in QT/OpenGL

[Rajaneesh <raj...@gm...>]

Hello,

It got resolved. It was related to Python Binding configuration

Regards
Rajaneesh

On Wed, Jul 11, 2018 at 4:24 PM, Rajaneesh <raj...@gm...>
wrote:

> Hello,
>
>   I was creating my own GUI for a custom scenario. I was getting the
> following error
>
> "AttributeError: 'Window' object has no attribute 'omplSetup'"..Kinldy
> suggest
>
> Code snippet is shown below.
>
> Regards
> Rajaneesh
>
>
> class Window(QtGui.QWidget):
>     def __init__(self):
>         super(Window, self).__init__()
>
>         self.omplSetup.setRobotMesh(self.robotFile)
>         self.mainWidget.glViewer.setRobot(self.omplSetup.renderRobot())
>
>         self.omplSetup.setEnvironmentMesh(self.environmentFile)
>         self.mainWidget.glViewer.setEnvironment(self.omplSetup.
> renderEnvironment())
>         self.glWidget = GLViewer()
>         self.button = self.createButton()
>
>         mainLayout = QtGui.QHBoxLayout()
>         mainLayout.addWidget(self.glWidget)
>         #mainLayout.addWidget(self.button)
>         self.setLayout(mainLayout)
>         self.setWindowTitle("OMPL Path")
>

[ompl-users] Using omplSetup in QT/OpenGL

[Rajaneesh <raj...@gm...>]

Hello,

  I was creating my own GUI for a custom scenario. I was getting the
following error

"AttributeError: 'Window' object has no attribute 'omplSetup'"..Kinldy
suggest

Code snippet is shown below.

Regards
Rajaneesh


class Window(QtGui.QWidget):
    def __init__(self):
        super(Window, self).__init__()

        self.omplSetup.setRobotMesh(self.robotFile)
        self.mainWidget.glViewer.setRobot(self.omplSetup.renderRobot())

        self.omplSetup.setEnvironmentMesh(self.environmentFile)

self.mainWidget.glViewer.setEnvironment(self.omplSetup.renderEnvironment())
        self.glWidget = GLViewer()
        self.button = self.createButton()

        mainLayout = QtGui.QHBoxLayout()
        mainLayout.addWidget(self.glWidget)
        #mainLayout.addWidget(self.button)
        self.setLayout(mainLayout)
        self.setWindowTitle("OMPL Path")

Re: [ompl-users] Query on Kinematic/Dynamic Planning and MultiRigidBodies

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

See the documentation for ompl::control::PathControl::printAsMatrix <http://ompl.kavrakilab.org/classompl_1_1control_1_1PathControl.html#ac6a0c9a65fc726a2e49b88a3230ec9aa>:

Print the path as a real-valued matrix where the i-th row represents the i-th state along the path, followed by the control and duration needed to reach this state. For the first state the control and duration are zeroes. The state components printed are those returned by ompl::base::StateSpace::copyToReals <http://ompl.kavrakilab.org/classompl_1_1base_1_1StateSpace.html#ac5e6b9f828da8d02338d55857ca74fda>, while the control components printed are the discrete components (if any) followed by the real-valued ones as returned by ompl::control::ControlSpace::getValueAddressAtIndex <http://ompl.kavrakilab.org/classompl_1_1control_1_1ControlSpace.html#adbb27f9ea57bcd3b8ad91fe8ef5d2a42>.

The omplapp code should already check whether the robots collide with each other. Is this not working? If so, please open a new issue describing the problem and attach a minimal working example.

Mark



> On Jul 9, 2018, at 2:38 AM, Rajaneesh <raj...@gm...> wrote:
> 
> Hello
> 
>  While executing KinematicCarPlanning with initial  state {0,0,,0} and final state as {2,2,pi}, the printMatix prints 6 column. The first three states looks like the states of interest. What do the last three column data represent
> 
> In DynamicCarPlanning, the printMatrix returns 8 column and the code contins 5 start and goal states
> 
> Can I get a pointer for reference materials for which these case studies were implemented?
> 
> 
> 
> In SE2MultiRigidBody planning, the two robots path is established. Is it possible to do collision check for two robots also rather than a robot and environment? Also both of the robots arrive at the path in same iteration count, though the sources/destinations of each of the robots were different. Was there any interpolation/extrapolation done to get the solution for both robot in same iterations?
> 
> 
> Thanks & Regards
> Rajaneesh
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
> ompl-users mailing list
> omp...@li...
> https://lists.sourceforge.net/lists/listinfo/ompl-users

[ompl-users] Query on Kinematic/Dynamic Planning and MultiRigidBodies

[Rajaneesh <raj...@gm...>]

Hello

 While executing KinematicCarPlanning with initial  state {0,0,,0} and
final state as {2,2,pi}, the printMatix prints 6 column. The first three
states looks like the states of interest. What do the last three column
data represent

In DynamicCarPlanning, the printMatrix returns 8 column and the code
contins 5 start and goal states

Can I get a pointer for reference materials for which these case studies
were implemented?



In SE2MultiRigidBody planning, the two robots path is established. Is it
possible to do collision check for two robots also rather than a robot and
environment? Also both of the robots arrive at the path in same iteration
count, though the sources/destinations of each of the robots were
different. Was there any interpolation/extrapolation done to get the
solution for both robot in same iterations?


Thanks & Regards
Rajaneesh

Re: [ompl-users] Virtual Obstacles in State Space

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

Hi Rajaneesh,

Yes, you’ll have to write you own state validity checker whose isValid() method returns false when the robot intersects the virtual obstacles.

Mark



> On Jul 6, 2018, at 1:39 PM, Rajaneesh <raj...@gm...> wrote:
> 
> Hello,
> 
>   Is it possible to define virtual obstacle in state space in OMPL. Though these obstacles are not part of current physical environment, they are necessarily no go areas for the robots in the state space. This is to formulating path using OMPL anticipating the robot or environment may be subjected to future modification in near future.
> 
> Regards
> Rajaneesh

[ompl-users] Virtual Obstacles in State Space

[Rajaneesh <raj...@gm...>]

Hello,

  Is it possible to define virtual obstacle in state space in OMPL. Though
these obstacles are not part of current physical environment, they are
necessarily no go areas for the robots in the state space. This is to
formulating path using OMPL anticipating the robot or environment may be
subjected to future modification in near future.

Regards
Rajaneesh

Re: [ompl-users] Does the weight of the object to be picked by an arm manipulator, influence the path planning by OMPL

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

Hi Deepak,


> On Jun 24, 2018, at 11:06 AM, Deepak <dpa...@gm...> wrote:
> Thanks, I'll check them out. Just to be clear, the control planners you've mentioned also, doesn't factor payload into account am I right?

They could, if you model your system dynamics and constraints correctly. You have to implement a StatePropagator-derived class, which encapsulates how to evolve the state of your system as a function of a start state, a control input and time duration. You also need to implement a StateValidityChecker-derived class, which usually performs collision checking and checks whether all velocities, accelerations, forces, and torques are within the desired bounds.

> Or, we could potentially give a cost function to the control planners and optimise it for say, grip posture, end effector velocity etc.

Currently, the planners in the ompl::control namespace cannot optimize over arbitrary cost functions. The ompl::control::SST computes asymptotically near-optimal paths in terms of path length.

> I am asking it again here because, I have a problem statement where I have to take into account the grasp angle and end effector velocity based on payload. I am looking for possible leads to investigate and research.
> 
> On Sun 24 Jun, 2018, 03:52 Mark Moll, <mm...@ri... <mailto:mm...@ri...>> wrote:
> Hi Deepak,
> 
> Just a minor clarification: OMPL has several planning algorithms capable of solving motion planning problems with dynamics constraints. These are all in the ompl::control namespace. See http://ompl.kavrakilab.org/planners.html <http://ompl.kavrakilab.org/planners.html>. There are several demos included with OMPL that show off how you can use these planners.
> 
> Mark
> 
> 
> 
>> On Jun 23, 2018, at 12:31 AM, Deepak <dpa...@gm... <mailto:dpa...@gm...>> wrote:
>> 
>> Hello Mark,
>> 
>> Thank you so much for your time and response. Appreciate it.
>> 
>> I will look up at the link that you gave me. I understood that the responsibility area of OMPL is only geometric planning and kinematic solving.
>> 
>> Thanks once more for taking time out for answering novice questions.
>> 
>> Regards,
>> 
>> Deepak
>> 
>> 
>> On Sat 23 Jun, 2018, 09:15 Mark Moll, <mm...@ri... <mailto:mm...@ri...>> wrote:
>> Hi Deepak,
>> 
>> You might have better luck asking your MoveIt! questions on https://discourse.ros.org <https://discourse.ros.org/>. MoveIt! uses OMPL’s planners in the ompl::geometric namespace, which—as the name suggests—only perform geometric/kinematic planning and don’t consider the manipulator weight.
>> 
>> If the arm has a payload of 150kg and MoveIt! cannot find a path for lifting up a 3kg object, I doubt that manipulator weight is the problem. There must be something else that is off about your setup.
>> 
>> Best,
>> Mark
>> 
>> 
>> 
>>> On Jun 21, 2018, at 4:15 AM, Deepak <dpa...@gm... <mailto:dpa...@gm...>> wrote:
>>> 
>>> Hello ompl-users,
>>> 
>>> Sorry if this is the wrong way to raise a query in this forum. I did not find any other link to raise a question.
>>> 
>>> I am pretty new to ROS and Robotics. I raised this same question in ROS answers forum and robotics.stackexchange.com <http://robotics.stackexchange.com/>,
>>> 
>>> But I could not get any answers.  Pardon my naiveté in this sort of question.
>>> 
>>> Does the weight of the object to be picked by an arm manipulator, influence the trajectory/path planning by OMPL?
>>> 
>>> If yes, could someone explain how by tweaking some settings, we can get it to plan for heavier object lifting trajectories?
>>> 
>>> So that it can maintain the end effector pose after picking an heavy item and maintain its velocity/acceleration, so that it does not fall.
>>> 
>>> How do I go about approaching a problem like this? Any keywords onto where to carryout my search to solve this problem, also would be of great help.
>>> 
>>> For some context, I could successfully use the KUKA arm model from the following git link,
>>> 
>>> https://github.com/udacity/RoboND-Kinematics-Project <https://github.com/udacity/RoboND-Kinematics-Project>
>>>  The KUKA arm is pretty powerful and the model used in simulation is capable of payloads upto 150Kg.
>>> 
>>> However, when I tried to lift a cylidrical object weighing 3 kgs, the KUKA arm would not pick up.
>>> 
>>> Kindly help me with any pointers. Thank you for your time in advance.
>>> 
>>> Regards,
>>> 
>>> Deepak
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org <http://slashdot.org/>! http://sdm.link/slashdot_______________________________________________ <http://sdm.link/slashdot_______________________________________________>
>>> ompl-users mailing list
>>> omp...@li... <mailto:omp...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/ompl-users <https://lists.sourceforge.net/lists/listinfo/ompl-users>
>> 
> 

[ompl-users] OMPL 1.4.0 released

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

Hi all,

We are  are happy to announce version 1.4.0 of the Open Motion Planning Library (OMPL).

OMPL 1.4 contains the following main changes:

There is a new framework for planning with constraints that unifies and generalizes prior proposed algorithms such as CBiRRT2, AtlasRRT and TangentBundle-RRT. The framework decouples the methodology used for computing configurations that satisfy constraints from the high-level planning strategy. This allows the user to use any sampling-based planning algorithm in OMPL with arbitrary geometric constraints. See the overview <file:///Users/mmoll/src/ompl.github.io/constrainedPlanning.html>, tutorial <file:///Users/mmoll/src/ompl.github.io/constrainedPlanningTutorial.html> and various demos <file:///Users/mmoll/src/ompl.github.io/group__demos.html> in ompl/demos/constraint.
Eigen3 is now a required dependency.
Various BIT* improvements.
PRM and RRTConnect can now return approximate solutions if an exact solution cannot be found. (This feature was already supported by several other planning algorithms in previous versions of OMPL.)
Added support for Spot <https://spot.lrde.epita.fr/>, a library that can be used to create finite automata from LTL specifications. This can be used by ompl::control::LTLPlanner <file:///Users/mmoll/src/ompl.github.io/classompl_1_1control_1_1LTLPlanner.html>. See the LTL with triangulation demo <file:///Users/mmoll/src/ompl.github.io/LTLWithTriangulation_8cpp_source.html>.
A new method has been added, ompl::geometric::PathSimplifier::perturbPath <file:///Users/mmoll/src/ompl.github.io/classompl_1_1geometric_1_1PathSimplifier.html#a3006b09d80ec5543b0b9b81e94046df2>, which can locally optimize a path with respect to a user-specified optimization objective. Existing methods of ompl::geometric::PathSimplifier <file:///Users/mmoll/src/ompl.github.io/classompl_1_1geometric_1_1PathSimplifier.html> are now also cost-aware.
ompl::geometric::PathHybridization <file:///Users/mmoll/src/ompl.github.io/classompl_1_1geometric_1_1PathHybridization.html> can now also optimize paths with respect to a user-specified optimization objective.
Fix for bugs in path simplification and interpolation that could cause path simplification to produce a path that was invalid or longer than the original path when using GoalRegions (as opposed to just one GoalState).
Added an option to RRT to add intermediate states during tree extension (this matches the same option that already existed in RRTConnect).
Added the Bridge Test Sampler.
Misc. bug fixes.

Major contributions to this release were made by:
• Zak Kingston, Rice University
• Bryce Willey, Rice University
• Jonathan Gammell, Oxford University
• Andreas Orthey, National Institute of Advanced Industrial Science and Technology (AIST)

The OMPL web page can be found at http://ompl.kavrakilab.org.


Best,

Mark

--
Mark Moll
Sr. Research Scientist   |   http://mmoll.rice.edu   |   713-348-5934
Rice University, Dept. of Computer Science — MS 132, PO Box 1892, Houston, TX 77251

Re: [ompl-users] Does the weight of the object to be picked by an arm manipulator, influence the path planning by OMPL

[Deepak <dpa...@gm...>]

Hello,

Thanks, I'll check them out. Just to be clear, the control planners you've
mentioned also, doesn't factor payload into account am I right?

Or, we could potentially give a cost function to the control planners and
optimise it for say, grip posture, end effector velocity etc.

I am asking it again here because, I have a problem statement where I have
to take into account the grasp angle and end effector velocity based on
payload. I am looking for possible leads to investigate and research.

On Sun 24 Jun, 2018, 03:52 Mark Moll, <mm...@ri...> wrote:

> Hi Deepak,
>
> Just a minor clarification: OMPL has several planning algorithms capable
> of solving motion planning problems with dynamics constraints. These are
> all in the ompl::control namespace. See
> http://ompl.kavrakilab.org/planners.html. There are several demos
> included with OMPL that show off how you can use these planners.
>
> Mark
>
>
>
> On Jun 23, 2018, at 12:31 AM, Deepak <dpa...@gm...> wrote:
>
> Hello Mark,
>
> Thank you so much for your time and response. Appreciate it.
>
> I will look up at the link that you gave me. I understood that the
> responsibility area of OMPL is only geometric planning and kinematic
> solving.
>
> Thanks once more for taking time out for answering novice questions.
>
> Regards,
>
> Deepak
>
>
> On Sat 23 Jun, 2018, 09:15 Mark Moll, <mm...@ri...> wrote:
>
>> Hi Deepak,
>>
>> You might have better luck asking your MoveIt! questions on
>> https://discourse.ros.org. MoveIt! uses OMPL’s planners in the
>> ompl::geometric namespace, which—as the name suggests—only perform
>> geometric/kinematic planning and don’t consider the manipulator weight.
>>
>> If the arm has a payload of 150kg and MoveIt! cannot find a path for
>> lifting up a 3kg object, I doubt that manipulator weight is the problem.
>> There must be something else that is off about your setup.
>>
>> Best,
>> Mark
>>
>>
>>
>> On Jun 21, 2018, at 4:15 AM, Deepak <dpa...@gm...> wrote:
>>
>> Hello ompl-users,
>>
>> Sorry if this is the wrong way to raise a query in this forum. I did not
>> find any other link to raise a question.
>>
>> I am pretty new to ROS and Robotics. I raised this same question in ROS
>> answers forum and robotics.stackexchange.com,
>>
>> But I could not get any answers.  Pardon my naiveté in this sort of
>> question.
>>
>> Does the weight of the object to be picked by an arm manipulator,
>> influence the trajectory/path planning by OMPL?
>>
>> If yes, could someone explain how by tweaking some settings, we can get
>> it to plan for heavier object lifting trajectories?
>>
>> So that it can maintain the end effector pose after picking an heavy item
>> and maintain its velocity/acceleration, so that it does not fall.
>>
>> How do I go about approaching a problem like this? Any keywords onto
>> where to carryout my search to solve this problem, also would be of
>> great help.
>>
>> For some context, I could successfully use the KUKA arm model from the
>> following git link,
>>
>> https://github.com/udacity/RoboND-Kinematics-Project
>>
>>  The KUKA arm is pretty powerful and the model used in simulation is
>> capable of payloads upto 150Kg.
>>
>> However, when I tried to lift a cylidrical object weighing 3 kgs, the
>> KUKA arm would not pick up.
>>
>> Kindly help me with any pointers. Thank you for your time in advance.
>>
>> Regards,
>>
>> Deepak
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org <http://slashdot.org/>!
>> http://sdm.link/slashdot_______________________________________________
>> ompl-users mailing list
>> omp...@li...
>> https://lists.sourceforge.net/lists/listinfo/ompl-users
>>
>>
>>
>

Re: [ompl-users] Does the weight of the object to be picked by an arm manipulator, influence the path planning by OMPL

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

Hi Deepak,

Just a minor clarification: OMPL has several planning algorithms capable of solving motion planning problems with dynamics constraints. These are all in the ompl::control namespace. See http://ompl.kavrakilab.org/planners.html <http://ompl.kavrakilab.org/planners.html>. There are several demos included with OMPL that show off how you can use these planners.

Mark



> On Jun 23, 2018, at 12:31 AM, Deepak <dpa...@gm...> wrote:
> 
> Hello Mark,
> 
> Thank you so much for your time and response. Appreciate it.
> 
> I will look up at the link that you gave me. I understood that the responsibility area of OMPL is only geometric planning and kinematic solving.
> 
> Thanks once more for taking time out for answering novice questions.
> 
> Regards,
> 
> Deepak
> 
> 
> On Sat 23 Jun, 2018, 09:15 Mark Moll, <mm...@ri... <mailto:mm...@ri...>> wrote:
> Hi Deepak,
> 
> You might have better luck asking your MoveIt! questions on https://discourse.ros.org <https://discourse.ros.org/>. MoveIt! uses OMPL’s planners in the ompl::geometric namespace, which—as the name suggests—only perform geometric/kinematic planning and don’t consider the manipulator weight.
> 
> If the arm has a payload of 150kg and MoveIt! cannot find a path for lifting up a 3kg object, I doubt that manipulator weight is the problem. There must be something else that is off about your setup.
> 
> Best,
> Mark
> 
> 
> 
>> On Jun 21, 2018, at 4:15 AM, Deepak <dpa...@gm... <mailto:dpa...@gm...>> wrote:
>> 
>> Hello ompl-users,
>> 
>> Sorry if this is the wrong way to raise a query in this forum. I did not find any other link to raise a question.
>> 
>> I am pretty new to ROS and Robotics. I raised this same question in ROS answers forum and robotics.stackexchange.com <http://robotics.stackexchange.com/>,
>> 
>> But I could not get any answers.  Pardon my naiveté in this sort of question.
>> 
>> Does the weight of the object to be picked by an arm manipulator, influence the trajectory/path planning by OMPL?
>> 
>> If yes, could someone explain how by tweaking some settings, we can get it to plan for heavier object lifting trajectories?
>> 
>> So that it can maintain the end effector pose after picking an heavy item and maintain its velocity/acceleration, so that it does not fall.
>> 
>> How do I go about approaching a problem like this? Any keywords onto where to carryout my search to solve this problem, also would be of great help.
>> 
>> For some context, I could successfully use the KUKA arm model from the following git link,
>> 
>> https://github.com/udacity/RoboND-Kinematics-Project <https://github.com/udacity/RoboND-Kinematics-Project>
>>  The KUKA arm is pretty powerful and the model used in simulation is capable of payloads upto 150Kg.
>> 
>> However, when I tried to lift a cylidrical object weighing 3 kgs, the KUKA arm would not pick up.
>> 
>> Kindly help me with any pointers. Thank you for your time in advance.
>> 
>> Regards,
>> 
>> Deepak
>> 
>> 
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org <http://slashdot.org/>! http://sdm.link/slashdot_______________________________________________ <http://sdm.link/slashdot_______________________________________________>
>> ompl-users mailing list
>> omp...@li... <mailto:omp...@li...>
>> https://lists.sourceforge.net/lists/listinfo/ompl-users <https://lists.sourceforge.net/lists/listinfo/ompl-users>
> 

Re: [ompl-users] Does the weight of the object to be picked by an arm manipulator, influence the path planning by OMPL

[Deepak <dpa...@gm...>]

Hello Mark,

Thank you so much for your time and response. Appreciate it.

I will look up at the link that you gave me. I understood that the
responsibility area of OMPL is only geometric planning and kinematic
solving.

Thanks once more for taking time out for answering novice questions.

Regards,

Deepak


On Sat 23 Jun, 2018, 09:15 Mark Moll, <mm...@ri...> wrote:

> Hi Deepak,
>
> You might have better luck asking your MoveIt! questions on
> https://discourse.ros.org. MoveIt! uses OMPL’s planners in the
> ompl::geometric namespace, which—as the name suggests—only perform
> geometric/kinematic planning and don’t consider the manipulator weight.
>
> If the arm has a payload of 150kg and MoveIt! cannot find a path for
> lifting up a 3kg object, I doubt that manipulator weight is the problem.
> There must be something else that is off about your setup.
>
> Best,
> Mark
>
>
>
> On Jun 21, 2018, at 4:15 AM, Deepak <dpa...@gm...> wrote:
>
> Hello ompl-users,
>
> Sorry if this is the wrong way to raise a query in this forum. I did not
> find any other link to raise a question.
>
> I am pretty new to ROS and Robotics. I raised this same question in ROS
> answers forum and robotics.stackexchange.com,
>
> But I could not get any answers.  Pardon my naiveté in this sort of
> question.
>
> Does the weight of the object to be picked by an arm manipulator,
> influence the trajectory/path planning by OMPL?
>
> If yes, could someone explain how by tweaking some settings, we can get it
> to plan for heavier object lifting trajectories?
>
> So that it can maintain the end effector pose after picking an heavy item
> and maintain its velocity/acceleration, so that it does not fall.
>
> How do I go about approaching a problem like this? Any keywords onto where
> to carryout my search to solve this problem, also would be of great help.
>
> For some context, I could successfully use the KUKA arm model from the
> following git link,
>
> https://github.com/udacity/RoboND-Kinematics-Project
>
>  The KUKA arm is pretty powerful and the model used in simulation is
> capable of payloads upto 150Kg.
>
> However, when I tried to lift a cylidrical object weighing 3 kgs, the KUKA
> arm would not pick up.
>
> Kindly help me with any pointers. Thank you for your time in advance.
>
> Regards,
>
> Deepak
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org!
> http://sdm.link/slashdot_______________________________________________
> ompl-users mailing list
> omp...@li...
> https://lists.sourceforge.net/lists/listinfo/ompl-users
>
>
>