ompl-users — Users mailing list

Re: [ompl-users] Accessing joint angle values inside OMPL

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

Hello Mark,

I found out that the state information is passed back to Move it! from
OMPL and then it is getting converted to joint angles. Sorry for bothering
you.

Regards

Deepak

On Wed 14 Nov, 2018, 17:02 Deepak <dpa...@gm... wrote:

> Hello Mark,
>
> I need to access the joint angle values inside Path Geometry class, for a
> robotic arm path planning problem. When I print the state information using
> printState API, I can see the joint angles getting printed. However I am
> unable to track from where the joint angles are getting populated and
> printed onto the console.
>
> Any help or pointers appreciated.
>

[ompl-users] Accessing joint angle values inside OMPL

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

Hello Mark,

I need to access the joint angle values inside Path Geometry class, for a
robotic arm path planning problem. When I print the state information using
printState API, I can see the joint angles getting printed. However I am
unable to track from where the joint angles are getting populated and
printed onto the console.

Any help or pointers appreciated.

[ompl-users] How to get the rpy given co-planar points?

[itfanr <bj...@gm...>]

Hello everyone,

I have a 3-D circle and know the axis of all the points.But now I want my
robot arm to draw the circle, and only axis is not enougth.

How to get the rpy given  co-planar points?

same question:
https://www.mathworks.com/matlabcentral/answers/298940-how-to-calculate-roll-pitch-and-yaw-from-xyz-coordinates-of-3-planar-points

Thank you.

Re: [ompl-users] Setting maximum waypoints to OMPL planner

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

Dear Mark,

Thanks for your quick response. I will check it out.

On Fri 12 Oct, 2018, 00:07 Mark Moll, <mm...@ri...> wrote:

> Hi Deepak,
>
> You may have better luck with
> ompl::geometric::PathSimplifier::shortcutPath, but even with that function
> there is no way to specify the desired maximum number of waypoints.
>
> Note that it may not always be possible to reduce a given path to one with
> only N waypoints (even if many solution paths exist that are reducible to N
> waypoints).
>
> Best,
>
> Mark
>
>
> > On Oct 11, 2018, at 4:59 AM, Deepak <dpa...@gm...> wrote:
> >
> > Hello,
> >
> > I would like to know if there is any way to specify to OMPL planner the
> maximum waypoints that I require. I checked out the reduceVertices() API,
> but it doesn't always assure removing a waypoint.
> >
> > My use case is that, between start and end goal, I want no more than 'N'
> waypoints. This N can vary based on my use case.
> >
> > Kindly guide me if you have any ideas as to how I can go about
> implementing this.
> >
> > Regards,
> >
> > Deepak
> > _______________________________________________
> > ompl-users mailing list
> > omp...@li...
> > https://lists.sourceforge.net/lists/listinfo/ompl-users
>
>

Re: [ompl-users] Setting maximum waypoints to OMPL planner

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

Hi Deepak,

You may have better luck with ompl::geometric::PathSimplifier::shortcutPath, but even with that function there is no way to specify the desired maximum number of waypoints. 

Note that it may not always be possible to reduce a given path to one with only N waypoints (even if many solution paths exist that are reducible to N waypoints).

Best,

Mark


> On Oct 11, 2018, at 4:59 AM, Deepak <dpa...@gm...> wrote:
> 
> Hello,
> 
> I would like to know if there is any way to specify to OMPL planner the maximum waypoints that I require. I checked out the reduceVertices() API, but it doesn't always assure removing a waypoint.
> 
> My use case is that, between start and end goal, I want no more than 'N' waypoints. This N can vary based on my use case.
> 
> Kindly guide me if you have any ideas as to how I can go about implementing this.
> 
> Regards,
> 
> Deepak
> _______________________________________________
> ompl-users mailing list
> omp...@li...
> https://lists.sourceforge.net/lists/listinfo/ompl-users

[ompl-users] Setting maximum waypoints to OMPL planner

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

Hello,

I would like to know if there is any way to specify to OMPL planner the
maximum waypoints that I require. I checked out the reduceVertices() API,
but it doesn't always assure removing a waypoint.

My use case is that, between start and end goal, I want no more than 'N'
waypoints. This N can vary based on my use case.

Kindly guide me if you have any ideas as to how I can go about implementing
this.

Regards,

Deepak

Re: [ompl-users] Info ompl cforest

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

Hi Luigi,

Can you run CFOREST with just one thread? By default, it will run RRT* in that thread and CFOREST and “normal” RRT* should behave the same way. If that’s not the case, the problem is definitely in CFOREST. 

Best,

Mark


> On Sep 26, 2018, at 12:09 PM, pal...@cs... wrote:
> 
> Hi all,
> 
> one question regarding a strange behavior that i have seen while using CForest with a state space that i implemented, which extends SO2. 
> 
> Sometimes the planner is generating a solution that goes through the obstacles, not respecting the given collision checker. RRT* with the same state space and collision checking instead works properly.
> 
> Do you have any possible guess of what generates the issue? A mistake in the state space (perhaps something related to the copying of the states)? 
> 
> Thanks for any help.
> 
> Luigi 
> _______________________________________________
> ompl-users mailing list
> omp...@li...
> https://lists.sourceforge.net/lists/listinfo/ompl-users

[ompl-users] Info ompl cforest

[<pal...@cs...>]

Hi all,
one question regarding a strange behavior that i have seen while using CForest with a state space that i implemented, which extends SO2. 
Sometimes the planner is generating a solution that goes through the obstacles, not respecting the given collision checker. RRT* with the same state space and collision checking instead works properly.
Do you have any possible guess of what generates the issue? A mistake in the state space (perhaps something related to the copying of the states)? 
Thanks for any help.
Luigi 

Re: [ompl-users] planning for a car-like robot

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

Hi Aswin,

No, it wouldn’t be a Dubins vehicle anymore. Of course, you can copy the Dubins-related code and make your own state space.

Best,

Mark


> On Sep 11, 2018, at 2:45 AM, Aswin Thomas <asw...@gm...> wrote:
> 
> Mark,
> Would it be possible to force the Dubins curve to be generated only towards say left direction i.e. for a robot that is only capable of turning left but not right.
> 
> Aswin
> 
> On Wed, Jul 2, 2014 at 10:12 PM Mark Moll <mm...@ri...> wrote:
> Hi Aswin,
> 
> My answers to your questions are below.
> 
> On Jul 1, 2014, at 9:38 PM, Aswin Thomas <asw...@gm...> wrote:
> 
> > Hi all,
> > I am new to OMPL and need your help on how to implement planning for a car-like robot. Below is the code I put together for a kinematic car after looking at the tutorials.
> >
> > I would like to know a few things:
> >
> > 1) I am assuming planning with controls is the way to obtain trajectory planning in sampling based planning. How can I make this code better?
> 
> Most of the control-based planners can take advantage of a steering function if you implement one. We have made that a little easier very recently (as in: it’s in our bitbucket/github repositories, but not in the latest release). For the particular system of interest you need to implement a StatePropagator-derived class that, in addition to the propagate method, implements a steer() method and a canSteer() method which simply returns true. If you use, e.g., ompl::control::RRT as your planner it will automatically use your steer method.
> 
> > 2) I understand there is no optimal planning with controls in OMPL (e.g. using RRTstar). Is this implementation possible and if so, how do I go about doing it.
> 
> It’s definitely possible. See, e.g.:
> http://arxiv.org/pdf/1205.5088.pdf
> http://ares.lids.mit.edu/papers/Karaman.Frazzoli.ICRA13.pdf
> http://www.pracsyslab.org/node/123
> 
> I haven’t checked if there any practical hurdles in implementing these algorithms using OMPL.
> 
> > 3) I only obtain a single path solution. Why does it not return multiple solutions? The C-space seems to be completely explored
> 
> The planner used simply terminates after the first solution is found. While the rest of the C-space may have been explored, the paths going through the rest of the C-space may not lead to a solution (i.e., they don’t reach the goal).
> 
> 
> > Code:
> > ob::StateSpacePtr space(new ob::DubinsStateSpace());
> 
> This is an interesting design choice. It will make your car more likely to find paths where the car drives forward but doesn’t prevent if from driving backwards (unless your KinematicCarODE doesn’t allow that either). The rest of the code looks fine to me.
> 
> > ob::RealVectorBounds bounds(2); bounds.setLow(-5); bounds.setHigh(11); // set the bounds for the R^2 part of SE(2)
> > space->as()->setBounds(bounds);
> >
> > oc::ControlSpacePtr cspace(new oc::RealVectorControlSpace(space,2)); // create a control space
> > ob::RealVectorBounds cbounds(2); // set the bounds for the control space
> > cbounds.setLow(0,0.0); cbounds.setHigh(0,2.0); //set forward velocity bounds
> > cbounds.setLow(1,-1.5); cbounds.setHigh(1,1.0); //set angular velocity bounds
> > cspace->as()->setBounds(cbounds);
> >
> > oc::SimpleSetup ss(cspace); // define a simple setup class
> > oc::SpaceInformationPtr si(ss.getSpaceInformation());
> > ss.setStateValidityChecker(boost::bind(&isStateValid,si.get(),_1)); // set state validity checking for this space
> >
> > oc::ODESolverPtr odeSolver(new oc::ODEBasicSolver<> (si, &KinematicCarODE));
> > ss.setStatePropagator(ompl::control::ODESolver::getStatePropagator(odeSolver));
> >
> > ob::ScopedState start(space); // create a start state
> > start->setX(0.0); start->setY(0.0); start->setYaw(0.0);
> > ob::ScopedState goal(space); // create a goal state; use the hard way to set the elements
> > goal->setX(10.0); goal->setY(10.0); goal->setYaw(0.0);
> > ss.setStartAndGoalStates(start, goal, 0.05);
> >
> > //set planner type
> > si->setMinMaxControlDuration(1,20);
> > si->setPropagationStepSize(0.06);
> > ob::PlannerPtr planner(new oc::RRT(si));
> > ss.setPlanner(planner);
> >
> > ob::PlannerStatus solved = ss.solve(50); // attempt to solve the problem within 50 second of planning time
> >
> > oc::PathControl& path(ss.getSolutionPath());
> > path.interpolate();
> > ob::PlannerData data(ss.getSpaceInformation());
> > ss.getPlanner()->getPlannerData(data);
> > std::vector allPaths;
> > allPaths = ss.getProblemDefinition()->getSolutions();
> > ROS_INFO(“%lu solution(s) found”,allPaths.size());
> >
> >
> >
> > Regards
> >
> > Aswin
> >
> > ------------------------------------------------------------------------------
> > Open source business process management suite built on Java and Eclipse
> > Turn processes into business applications with Bonita BPM Community Edition
> > Quickly connect people, data, and systems into organized workflows
> > Winner of BOSSIE, CODIE, OW2 and Gartner awards
> > http://p.sf.net/sfu/Bonitasoft_______________________________________________
> > ompl-users mailing list
> > omp...@li...
> > https://lists.sourceforge.net/lists/listinfo/ompl-users
> 
> --
> Mark Moll
> 
> 
> 

Re: [ompl-users] planning for a car-like robot

[Aswin T. <asw...@gm...>]

Mark,
Would it be possible to force the Dubins curve to be generated only towards
say left direction i.e. for a robot that is only capable of turning left
but not right.

Aswin

On Wed, Jul 2, 2014 at 10:12 PM Mark Moll <mm...@ri...> wrote:

> Hi Aswin,
>
> My answers to your questions are below.
>
> On Jul 1, 2014, at 9:38 PM, Aswin Thomas <asw...@gm...> wrote:
>
> > Hi all,
> > I am new to OMPL and need your help on how to implement planning for a
> car-like robot. Below is the code I put together for a kinematic car after
> looking at the tutorials.
> >
> > I would like to know a few things:
> >
> > 1) I am assuming planning with controls is the way to obtain trajectory
> planning in sampling based planning. How can I make this code better?
>
> Most of the control-based planners can take advantage of a steering
> function if you implement one. We have made that a little easier very
> recently (as in: it’s in our bitbucket/github repositories, but not in the
> latest release). For the particular system of interest you need to
> implement a StatePropagator-derived class that, in addition to the
> propagate method, implements a steer() method and a canSteer() method which
> simply returns true. If you use, e.g., ompl::control::RRT as your planner
> it will automatically use your steer method.
>
> > 2) I understand there is no optimal planning with controls in OMPL (e.g.
> using RRTstar). Is this implementation possible and if so, how do I go
> about doing it.
>
> It’s definitely possible. See, e.g.:
> http://arxiv.org/pdf/1205.5088.pdf
> http://ares.lids.mit.edu/papers/Karaman.Frazzoli.ICRA13.pdf
> http://www.pracsyslab.org/node/123
>
> I haven’t checked if there any practical hurdles in implementing these
> algorithms using OMPL.
>
> > 3) I only obtain a single path solution. Why does it not return multiple
> solutions? The C-space seems to be completely explored
>
> The planner used simply terminates after the first solution is found.
> While the rest of the C-space may have been explored, the paths going
> through the rest of the C-space may not lead to a solution (i.e., they
> don’t reach the goal).
>
>
> > Code:
> > ob::StateSpacePtr space(new ob::DubinsStateSpace());
>
> This is an interesting design choice. It will make your car more likely to
> find paths where the car drives forward but doesn’t prevent if from driving
> backwards (unless your KinematicCarODE doesn’t allow that either). The rest
> of the code looks fine to me.
>
> > ob::RealVectorBounds bounds(2); bounds.setLow(-5); bounds.setHigh(11);
> // set the bounds for the R^2 part of SE(2)
> > space->as()->setBounds(bounds);
> >
> > oc::ControlSpacePtr cspace(new oc::RealVectorControlSpace(space,2)); //
> create a control space
> > ob::RealVectorBounds cbounds(2); // set the bounds for the control space
> > cbounds.setLow(0,0.0); cbounds.setHigh(0,2.0); //set forward velocity
> bounds
> > cbounds.setLow(1,-1.5); cbounds.setHigh(1,1.0); //set angular velocity
> bounds
> > cspace->as()->setBounds(cbounds);
> >
> > oc::SimpleSetup ss(cspace); // define a simple setup class
> > oc::SpaceInformationPtr si(ss.getSpaceInformation());
> > ss.setStateValidityChecker(boost::bind(&isStateValid,si.get(),_1)); //
> set state validity checking for this space
> >
> > oc::ODESolverPtr odeSolver(new oc::ODEBasicSolver<> (si,
> &KinematicCarODE));
> >
> ss.setStatePropagator(ompl::control::ODESolver::getStatePropagator(odeSolver));
> >
> > ob::ScopedState start(space); // create a start state
> > start->setX(0.0); start->setY(0.0); start->setYaw(0.0);
> > ob::ScopedState goal(space); // create a goal state; use the hard way to
> set the elements
> > goal->setX(10.0); goal->setY(10.0); goal->setYaw(0.0);
> > ss.setStartAndGoalStates(start, goal, 0.05);
> >
> > //set planner type
> > si->setMinMaxControlDuration(1,20);
> > si->setPropagationStepSize(0.06);
> > ob::PlannerPtr planner(new oc::RRT(si));
> > ss.setPlanner(planner);
> >
> > ob::PlannerStatus solved = ss.solve(50); // attempt to solve the problem
> within 50 second of planning time
> >
> > oc::PathControl& path(ss.getSolutionPath());
> > path.interpolate();
> > ob::PlannerData data(ss.getSpaceInformation());
> > ss.getPlanner()->getPlannerData(data);
> > std::vector allPaths;
> > allPaths = ss.getProblemDefinition()->getSolutions();
> > ROS_INFO(“%lu solution(s) found”,allPaths.size());
> >
> >
> >
> > Regards
> >
> > Aswin
> >
> >
> ------------------------------------------------------------------------------
> > Open source business process management suite built on Java and Eclipse
> > Turn processes into business applications with Bonita BPM Community
> Edition
> > Quickly connect people, data, and systems into organized workflows
> > Winner of BOSSIE, CODIE, OW2 and Gartner awards
> >
> http://p.sf.net/sfu/Bonitasoft_______________________________________________
> > ompl-users mailing list
> > omp...@li...
> > https://lists.sourceforge.net/lists/listinfo/ompl-users
>
> --
> Mark Moll
>
>
>
>

Re: [ompl-users] Help me for making PRM Algorithm without PlannerManager

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

One problem with the code you attached is that the planner termination condition you define is just an empty function. Try passing in a timedPlannerTerminationCondition <http://ompl.kavrakilab.org/namespaceompl_1_1base.html#ae26e5f143063be389fba4906d438a381> to constructRoadmap().

Best,

Mark


> On Sep 10, 2018, at 3:21 AM, 이현태 <lee...@gm...> wrote:
> 
> Hi. I am making PRM Algorithm without PlannerManager plugin.
> 
> 
> I have to use the OMPL API, ompl::geometric::PRM Class
> 
> 
> For our project, I have to make a code of PRM one by one.
> 
> 
> But I have never seen any document or demo detail of PRM using API.
> 
> 
> I want to make two source codes, construct Roadmap and query phase.
> 
> 
> I am using ros-kinetic ,moveit and ROS-Industrial universal robot meta-package (http://wiki.ros.org/universal_robot) .
> 
> 
> I tried to use ompl::geometric::PRM::constructRoadmap (const base::PlannerTerminationCondition &ptc)   but failed….
> 
> 
> I don’t understanding setup for PRM.
> 
> 
> So can I get some document of demo of PRM implementation in detail??
> 
> 
> Please help me….
> 
> 
> I added the code I tried.
> 
> 
> Thank you for advance..

[ompl-users] Help me for making PRM Algorithm without PlannerManager

[이현태 <lee...@gm...>]

Hi. I am making PRM Algorithm without PlannerManager plugin.



I have to use the OMPL API, *ompl::geometric::PRM Class*



For our project, I have to make a code of PRM one by one.



But I have never seen any document or demo detail of PRM using API.



I want to make two source codes, construct Roadmap and query phase.



I am using ros-kinetic ,moveit and ROS-Industrial universal robot
meta-package (http://wiki.ros.org/universal_robot) .



I tried to use *ompl::geometric::PRM::**constructRoadmap*
<http://ompl.kavrakilab.org/classompl_1_1geometric_1_1PRM.html#a8da5dd602d45e477612bb1401cf68c19>
 (const *base::PlannerTerminationCondition*
<http://ompl.kavrakilab.org/classompl_1_1base_1_1PlannerTerminationCondition.html>
&ptc)
  but failed….



I don’t understanding setup for PRM.



So can I get some document of demo of PRM implementation in detail??



Please help me….



I added the code I tried.



Thank you for advance..

Re: [ompl-users] OMPL ABI compatible releases

[Leopold Palomo-A. <le...@al...>]

El 07/09/18 a les 16:01, Mark Moll ha escrit:
> Hi Leopold,
> 
> I did a diff between 1.3.0 and 1.3.1 and the API did change slightly. Mostly removing “const” from plain-old-datatypes like int and double in method arguments. I was trying to be cautious and bumped the ABI level, but that may not have been necessary.
> 
> The ABI number is not derived from the OMPL version. It’s simply a coincidence that at some point it synced up with the first two version numbers. I don’t understand why you would want to patch that. It’s not like anyone needs to remember ABI numbers. To me, it’s just a way for the dynamic library loader to verify that a compatible version is found. So I’d advise against patching the ABI version of OMPL 1.4.0.
> 

Ok,

I drop the patch and soon I will push to the debian archive. I will put
also an Ubuntu package.

OTOH I'm sorry for the python bindings, but the dependencies are
difficult to package in Debian. In any case, I hope that this autumn I
will make a new try and we can finally have a Python binding for OMPL.

Cheers,

Leo


-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [ompl-users] OMPL ABI compatible releases

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

> On Sep 7, 2018, at 3:45 AM, Leopold Palomo-Avellaneda <le...@al...> wrote:
> 
> On 07/09/18 09:12, Leopold Palomo-Avellaneda wrote:
>> On 06/09/18 16:04, Mark Moll wrote:
>>> Hi Leopold,
>>> 
>>> Yes, unless I made mistake. Patch-level releases should preserve ABI compatibility.
>>> 
>> 
>> Mark!!
>> 
>> ompl 1.3.3 install libompl.so.14 instead of 13. This is a mistake IMHO.
>> 
> 
> Mark,
> 
> checking OMPL_ABI_VERSION I have found:
> 
> 1.2.1 -> 12
> 1.3.0 -> 13
> 1.3.1 -> 14
> 1.3.2 -> 14
> 1.3.3 -> 14
> 1.4.0 -> 15
> 
> Are you aware of this? Pay attention that you jump one number from 1.3.0 and
> 1.3.1. and it's a pity because it was easy to remember that the first two digits
> means the ABI version.
> 
> I'm preparing a new debian package (1.4.0) and, could be problematic if I patch
> OMPL_ABI_VERSION to 14 instead of 15?


Hi Leopold,

I did a diff between 1.3.0 and 1.3.1 and the API did change slightly. Mostly removing “const” from plain-old-datatypes like int and double in method arguments. I was trying to be cautious and bumped the ABI level, but that may not have been necessary.

The ABI number is not derived from the OMPL version. It’s simply a coincidence that at some point it synced up with the first two version numbers. I don’t understand why you would want to patch that. It’s not like anyone needs to remember ABI numbers. To me, it’s just a way for the dynamic library loader to verify that a compatible version is found. So I’d advise against patching the ABI version of OMPL 1.4.0.

Best,

Mark

Re: [ompl-users] OMPL ABI compatible releases

[Leopold Palomo-A. <le...@al...>]

On 07/09/18 09:12, Leopold Palomo-Avellaneda wrote:
> On 06/09/18 16:04, Mark Moll wrote:
>> Hi Leopold,
>>
>> Yes, unless I made mistake. Patch-level releases should preserve ABI compatibility.
>>
> 
> Mark!!
> 
> ompl 1.3.3 install libompl.so.14 instead of 13. This is a mistake IMHO.
> 

Mark,

checking OMPL_ABI_VERSION I have found:

1.2.1 -> 12
1.3.0 -> 13
1.3.1 -> 14
1.3.2 -> 14
1.3.3 -> 14
1.4.0 -> 15

Are you aware of this? Pay attention that you jump one number from 1.3.0 and
1.3.1. and it's a pity because it was easy to remember that the first two digits
means the ABI version.

I'm preparing a new debian package (1.4.0) and, could be problematic if I patch
OMPL_ABI_VERSION to 14 instead of 15?

Leopold


-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [ompl-users] OMPL ABI compatible releases

[Leopold Palomo-A. <le...@al...>]

On 06/09/18 16:04, Mark Moll wrote:
> Hi Leopold,
> 
> Yes, unless I made mistake. Patch-level releases should preserve ABI compatibility.
> 

Mark!!

ompl 1.3.3 install libompl.so.14 instead of 13. This is a mistake IMHO.

Leo



-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [ompl-users] OMPL ABI compatible releases

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

Hi Leopold,

Yes, unless I made mistake. Patch-level releases should preserve ABI compatibility.

Best,

Mark


> On Sep 6, 2018, at 8:26 AM, Leopold Palomo-Avellaneda <le...@al...> wrote:
> 
> Hi Mark (and list)
> 
> I have seen [1] that of ompl there are 1.3.0, 1.3.1, 1.3.2 and 1.3.3.
> These versions are binary compatible?
> 
> Thx,
> 
> Leopold
> 
> 
> [1] https://bitbucket.org/ompl/ompl/downloads/
> 

[ompl-users] OMPL ABI compatible releases

[Leopold Palomo-A. <le...@al...>]

Hi Mark (and list)

I have seen [1] that of ompl there are 1.3.0, 1.3.1, 1.3.2 and 1.3.3.
These versions are binary compatible?

Thx,

Leopold


[1] https://bitbucket.org/ompl/ompl/downloads/


-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [ompl-users] samplers in compound statespace

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

Hi Rajaneesh,

You can do this by calling ompl::base::StateSpace::setStateSamplerAllocator with as argument a function that you have to write that will allocate the appropriate samplers for each subspace. If you want a valid state sampler, you can use the ompl::base::SpaceInformation::setValidStateSamplerAllocator method.

Best,

Mark


> On Aug 26, 2018, at 12:21 AM, Rajaneesh <raj...@gm...> wrote:
> 
> Hello,
> 
>   I have a compound space comprising of three  Vectorspaces. I would like to run the planner with uniform sampler in one vectorspace and gaussian sampler for the rest of the vector spaces. How would I do this in OMPL?
> 
> Regards
> Rajaneesh

[ompl-users] samplers in compound statespace

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

Hello,

  I have a compound space comprising of three  Vectorspaces. I would like
to run the planner with uniform sampler in one vectorspace and gaussian
sampler for the rest of the vector spaces. How would I do this in OMPL?

Regards
Rajaneesh

Re: [ompl-users] Narrow Passage Problem

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

You can explore on bridge test technique...

On Tue, 14 Aug 2018 16:04 riccardo carraro, <car...@ho...>
wrote:

> Hi Friends,
> I'm using a differential robot (a Turtlebot) and I'm facing the narrow
> passage problem.
> What is the best planner in order to solve this problem?
>
> ------------------------------------------------------------------------------
> 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] Narrow Passage Problem

[riccardo c. <car...@ho...>]

Hi Friends,
I'm using a differential robot (a Turtlebot) and I'm facing the narrow passage problem.
What is the best planner in order to solve this problem?

[ompl-users] Issues with installing and using ompl

[Amol L. <amo...@gm...>]

Hello,

I'm a graduate student doing my research in motion planning at Stony Brook
university. That's why I needed to use the ompl libraries with python
bindings and get started with development using these libraries.

I have been trying to install these libraries since a week or so, but
there's no success. I followed the instructions on the ompl website and
also checked with bitbucket for solutions to my errors, but still I haven't
been able to install them correctly.
I'm getting the following error:
Traceback (most recent call last):
  File "/home/amol/PycharmProjects/MotionPlanning/RigidBodyPlanning.py",
line 1, in <module>
    from ompl import base as ob
  File
"/home/amol/Documents/ompl-1.4.0-Source/py-bindings/ompl/base/__init__.py",
line 1, in <module>
    from ompl import util
  File
"/home/amol/Documents/ompl-1.4.0-Source/py-bindings/ompl/util/__init__.py",
line 4, in <module>
    from ompl.util._util import *
ModuleNotFoundError: No module named 'ompl.util._util'

I desperately need this libraries to be working on my system, so any help
would be greatly appreciated.

Thank you!

Amol Loya
Graduate Student Mechanical Engineering
Stony Brook University, NY
Cell - (631) 590-9098

Re: [ompl-users] coverage planning using ompl

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

Hi Aswin,

OMPL doesn’t have any coverage algorithms.

Best,

Mark


> On Aug 9, 2018, at 12:59 AM, Aswin Thomas <asw...@gm...> wrote:
> 
> Hi all,
> I would like to use ompl for performing coverage planning for a vaccum cleaner. Assume that the configuration space is a rectangular world with no obstacles. How do I start using ompl for this purpose. Any pointers would be helpful.
> 
> Aswin

[ompl-users] coverage planning using ompl

[Aswin T. <asw...@gm...>]

Hi all,
I would like to use ompl for performing coverage planning for a vaccum
cleaner. Assume that the configuration space is a rectangular world with no
obstacles. How do I start using ompl for this purpose. Any pointers would
be helpful.

Aswin