ompl-users — Users mailing list

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,

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...> 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://sdm.link/slashdot_______________________________________________
> ompl-users mailing list
> omp...@li...
> https://lists.sourceforge.net/lists/listinfo/ompl-users

[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 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

Re: [ompl-users] Informed RRT* for SE2 space

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

Hi Anand,

Informed RRT* will used the ellipsoidal heuristic for the R^2 subspace of SE(2) and rejection sampling for the SO(2) subspace. See the code in ompl/src/ompl/base/samplers/informed/src/PathLengthDirectInfSampler.cpp. This is specific to the path length optimization objective.

Best,
Mark



> On Jun 13, 2018, at 9:53 PM, Anand <ana...@gm...> wrote:
> 
> After reading the reference paper for Informed RRT* [https://arxiv.org/abs/1404.2334 <https://arxiv.org/abs/1404.2334>], it looks like you can sample using an ellipsoidal heuristic for Rn spaces. Is there an equivalent for SE2 spaces like the Reeds-Shepp state space?
> 
> It wasn't immediately clear by looking at the code. 

[ompl-users] Informed RRT* for SE2 space

[Anand <ana...@gm...>]

After reading the reference paper for Informed RRT* [
https://arxiv.org/abs/1404.2334], it looks like you can sample using an
ellipsoidal heuristic for Rn spaces. Is there an equivalent for SE2 spaces
like the Reeds-Shepp state space?

It wasn't immediately clear by looking at the code.

Re: [ompl-users] Install ompl app and ompl separately

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

Hi Luigi,

Any version of omplapp is only guaranteed to work with the corresponding version of ompl.

If there are problems with the installation directions, please open an issue on bitbucket (or email me).

Thanks,
Mark



> On May 7, 2018, at 3:20 AM, pal...@cs... wrote:
> 
> Hi all,
> 
> Is there an easy way to install ompl-app against an existing Installation of ompl? The Installation suggested by the readme file of the github package does not work right out of the box.
> 
> Thanks for your help.
> 
> Best,
> Luigi

Re: [ompl-users] Install ompl app and ompl separately

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

In my understanding, each of them require different bindings. So we cannot
reuse existing bindings

Regards-Raj

On Mon, May 7, 2018 at 1:50 PM, pal...@cs... <
pal...@cs...> wrote:

> Hi all,
>
> Is there an easy way to install ompl-app against an existing Installation
> of ompl? The Installation suggested by the readme file of the github
> package does not work right out of the box.
>
> Thanks for your help.
>
> Best,
> Luigi
>
> ------------------------------------------------------------
> ------------------
> 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] Install ompl app and ompl separately

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

Hi all, 
Is there an easy way to install ompl-app against an existing Installation of ompl? The Installation suggested by the readme file of the github package does not work right out of the box.
Thanks for your help. 
Best, Luigi 

Re: [ompl-users] kinodynamic planners in a compound space

[Guilherme A. S. P. <gpe...@uf...>]

I still have the same problems... Did anyone have a similar experience 
before?

Thanks,

Guilherme


Em 06/04/2018 11:22, Guilherme Augusto Silva Pereira escreveu:
> Hi all,
>
> I'm using OMPL to plan the movement of a robot in an environment with 
> obstacles. The robot is a manipulator of 5 DOF, all revolute joints, 
> on a non-holonomic mobile base. The joints have limited values (-PI/2 
> to PI/2). I'd like to use the kinodynamic planners from the library, 
> in special the RRT. So, based on HybridSystemPlanning.cpp example, 
> I've modeled the problem as follows: the state space was considered as 
> a compound space, like in the example. It has both SE(2) and R(5) sub 
> spaces. The collision avoidance was done in isStateValid function and 
> the states propagation was done in the propagate function.
>
> The algorithm is "working" so far, what means that the returned path 
> is in the free configuration space, and normally it ends closer to the 
> goal state than the initial state. However, the elapsed time is too 
> large in my opinion (about 30 seconds in some cases), and it ends 
> normally far from the goal state. I have two hypotheses about this: 
> maybe the default function isSatisfied and the default functions of 
> sampling are not good for my problem.
>
> I thus have some questions:
>
> Does isSatisfied default function take care of the topology of a 
> compound space in order to define a metric of distance to goal?
> Does the default sampling function polarizs to somewhere or it is 
> always uniform sampling?
>
> Searching at the internet, I was able to find examples of people who 
> used OMPL and got excellent results in therms of performance, even for 
> much more complicated problems, with more than fifteen DOF using 
> complicated compound spaces. They spend like one or two seconds in the 
> planning. The HybridSystemPlanning.cpp example is very quickly as 
> well, spending less than four seconds in almost all the 
> cases. Therefore, I think I can improve the performance of my 
> algorithm someway, maybe tuning some parameter. I'm trying to tune the 
> parameters PropagationStepSize and MinMaxControlDuration to improve 
> the performance. Is there any other parameter that I should look as well?
>
> I'm using the RRT planner, but maybe other planner is better. Except 
> RRT, is there other kinodynamic planner that doesn't use projections 
> or other specific function to work?
>
> And the last question: I'd like to finish the algorithm when a 
> Lyapunov function (that is function of the configuration) is lower 
> than a threshold, what means the planner do not need to arrive at the 
> goal state. I have searched in internet and I found two possible 
> solutions, use a terminate condition, or use the goal region class. In 
> my case, I think the terminate condition would be better, but I could 
> not find any example of how to implement it. Can you tell me how I 
> implement a termination condition?
>
> Thanks a lot,
> Guilherme
>
>
>
> -- 
>
> Prof. Guilherme A. S. Pereira
> Departamento de Engenharia Elétrica
> Universidade Federal de Minas Gerais
> Tel: +55 31 3409-6687
> http://www.ppgee.ufmg.br/~gpereira
>
>
> ------------------------------------------------------------------------------
> 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

-- 

Prof. Guilherme A. S. Pereira
Departamento de Engenharia Elétrica
Universidade Federal de Minas Gerais
Tel: +55 31 3409-6687
http://www.ppgee.ufmg.br/~gpereira

[ompl-users] kinodynamic planners in a compound space

[Guilherme A. S. P. <gpe...@uf...>]

Hi all,

I'm using OMPL to plan the movement of a robot in an environment with 
obstacles. The robot is a manipulator of 5 DOF, all revolute joints, 
on a non-holonomic mobile base. The joints have limited values (-PI/2 to 
PI/2). I'd like to use the kinodynamic planners from the library, in 
special the RRT. So, based on HybridSystemPlanning.cpp example, I've 
modeled the problem as follows: the state space was considered as a 
compound space, like in the example. It has both SE(2) and R(5) sub 
spaces. The collision avoidance was done in isStateValid function and 
the states propagation was done in the propagate function.

The algorithm is "working" so far, what means that the returned path is 
in the free configuration space, and normally it ends closer to the goal 
state than the initial state. However, the elapsed time is too large in 
my opinion (about 30 seconds in some cases), and it ends normally far 
from the goal state. I have two hypotheses about this: maybe the default 
function isSatisfied and the default functions of sampling are not good 
for my problem.

I thus have some questions:

Does isSatisfied default function take care of the topology of a 
compound space in order to define a metric of distance to goal?
Does the default sampling function polarizs to somewhere or it is always 
uniform sampling?

Searching at the internet, I was able to find examples of people who 
used OMPL and got excellent results in therms of performance, even for 
much more complicated problems, with more than fifteen DOF using 
complicated compound spaces. They spend like one or two seconds in the 
planning. The HybridSystemPlanning.cpp example is very quickly as well, 
spending less than four seconds in almost all the cases. Therefore, I 
think I can improve the performance of my algorithm someway, maybe 
tuning some parameter. I'm trying to tune the parameters 
PropagationStepSize and MinMaxControlDuration to improve the 
performance. Is there any other parameter that I should look as well?

I'm using the RRT planner, but maybe other planner is better. Except 
RRT, is there other kinodynamic planner that doesn't use projections or 
other specific function to work?

And the last question: I'd like to finish the algorithm when a Lyapunov 
function (that is function of the configuration) is lower than a 
threshold, what means the planner do not need to arrive at the goal 
state. I have searched in internet and I found two possible solutions, 
use a terminate condition, or use the goal region class. In my case, I 
think the terminate condition would be better, but I could not find any 
example of how to implement it. Can you tell me how I implement a 
termination condition?

Thanks a lot,
Guilherme



-- 

Prof. Guilherme A. S. Pereira
Departamento de Engenharia Elétrica
Universidade Federal de Minas Gerais
Tel: +55 31 3409-6687
http://www.ppgee.ufmg.br/~gpereira

Re: [ompl-users] Info complex benchmark

[Luigi P. <pal...@in...>]

Hi all,

still a couple of questions that I guess I could list under this topic.

When generating plots from the benchmarks databases using the 
ompl_benchmark_statistics.py script I do encounter in strange cost trades: some 
of the trends are increasing for some periods (see attached picture).

1. Is this expected? Could be the case that this is due to some initial 
solutions of high cost found very late in the planning process?
2. Would be it possible to use a logarithmic scale for this plots?

Thanks for the help!

Best,

Luigi


> ompl::tools::Benchmark b(simpleSetup, “myBenchmark");
> b.addExperimentParameter(“startX", “REAL", std::to_string(startX));
> b.addExperimentParameter(“startY", “REAL", std::to_string(startY));
> …
>
> PlannerArena has some support for parametrized benchmarks. Give it a try and 
> let me know if you need a different kind of visualization of the result.
>
> Mark
>
>
>
>> On Jan 18, 2018, at 7:52 AM, pal...@cs... 
>> <mailto:pal...@cs...> wrote:
>>
>> Hi all,
>>
>> One question regarding the ompl::tools::benchmark tool. I would like to have 
>> a benchmark where I could vary the start and goal positions. Is that 
>> possible? I see that we could vary the planner parameters, but usually start 
>> and goals are not considered as such. Any idea on how to do it?
>>
>> Thanks!
>>
>> Best Regards,
>>
>> Luigi
>
>
>
> ------------------------------------------------------------------------------
> 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

-- 
Luigi Palmieri,  M.Sc. in Engineering in Computer Science
PhD Candidate at Social Robotics Laboratory
Albert-Ludwigs-Universität Freiburg
skype: mr-luigi-palmieri
Home Page: http://www.informatik.uni-freiburg.de/~palmieri/

Re: [ompl-users] Compound Control Space

[Filippo B. <fil...@gm...>]

hi mark,
thanks for solving my issue and also for providing an example.
in my planning problem i need a compound control space composed by a R^n
real vector control space and a discrete control space
it's a model for a polygonal prism being pushed from only one side at once
(the discrete part is the side)

thanks again
Filippo

Il giorno lun 22 gen 2018 alle ore 16:29 Mark Moll <mm...@ri...> ha
scritto:

> Hi Filippo,
>
> This was an oversight. I pushed a commit to Bitbucket and GitHub that
> fixes this:
>
> https://bitbucket.org/ompl/ompl/commits/7334815d9fd2a0dae4c7619f7dbbe7e671ed8936
> (You will have to regenerate your python bindings.)
>
> I have attached a modified version of RigidBodyPlanning.py that shows how
> you can use this. It changes the control space from R^2 to a
> CompoundControlSpace with two copies of R.
>
> I am just curious, what kind of control space do you have that cannot be
> handled by RealVectorControlSpace?
>
> Best,
>
> Mark
>
>
>
> On Jan 19, 2018, at 3:19 AM, Filippo Bertoncelli <
> fil...@gm...> wrote:
>
> hello everybody, is it possible to use a compound control space using
> python?
> i've tried but it seems that i can't access the control value in the
> propagate function (in the demos compound state objects are accessed using
> the as() method, but "as" is a keyword in python and trying to use it as a
> method creates a syntax error) is there a way around this problem in python
> or i have to switch to c++?
> Thanks
> Filippo
>
>
>

Re: [ompl-users] Compound Control Space

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

Hi Filippo,

This was an oversight. I pushed a commit to Bitbucket and GitHub that fixes this:
https://bitbucket.org/ompl/ompl/commits/7334815d9fd2a0dae4c7619f7dbbe7e671ed8936
(You will have to regenerate your python bindings.)

I have attached a modified version of RigidBodyPlanning.py that shows how you can use this. It changes the control space from R^2 to a CompoundControlSpace with two copies of R.

I am just curious, what kind of control space do you have that cannot be handled by RealVectorControlSpace?

Best,

Mark



> On Jan 19, 2018, at 3:19 AM, Filippo Bertoncelli <fil...@gm...> wrote:
> 
> hello everybody, is it possible to use a compound control space using python?
> i've tried but it seems that i can't access the control value in the propagate function (in the demos compound state objects are accessed using the as() method, but "as" is a keyword in python and trying to use it as a method creates a syntax error) is there a way around this problem in python or i have to switch to c++?
> Thanks
> Filippo

Re: [ompl-users] Info complex benchmark

[Luigi P. <pal...@in...>]

Hi Mark,

thanks!

Luigi


On 01/18/2018 05:23 PM, Mark Moll wrote:
> Hi Luigi,
>
> For this you’d use the ompl::tools::Benchmark::addExperimentParameter 
> <http://ompl.kavrakilab.org/classompl_1_1tools_1_1Benchmark.html#afab48f173edc785ee005301642b1afb1> method 
> for that:
>
> // run a separate benchmark for all start and goal positions
> ompl::tools::Benchmark b(simpleSetup, “myBenchmark");
> b.addExperimentParameter(“startX", “REAL", std::to_string(startX));
> b.addExperimentParameter(“startY", “REAL", std::to_string(startY));
> …
>
> PlannerArena has some support for parametrized benchmarks. Give it a try and 
> let me know if you need a different kind of visualization of the result.
>
> Mark
>
>
>
>> On Jan 18, 2018, at 7:52 AM, pal...@cs... 
>> <mailto:pal...@cs...> wrote:
>>
>> Hi all,
>>
>> One question regarding the ompl::tools::benchmark tool. I would like to have 
>> a benchmark where I could vary the start and goal positions. Is that 
>> possible? I see that we could vary the planner parameters, but usually start 
>> and goals are not considered as such. Any idea on how to do it?
>>
>> Thanks!
>>
>> Best Regards,
>>
>> Luigi
>
>
>
> ------------------------------------------------------------------------------
> 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

-- 
Luigi Palmieri,  M.Sc. in Engineering in Computer Science
PhD Candidate at Social Robotics Laboratory
Albert-Ludwigs-Universität Freiburg
skype: mr-luigi-palmieri
Home Page: http://www.informatik.uni-freiburg.de/~palmieri/

[ompl-users] Compound Control Space

[Filippo B. <fil...@gm...>]

hello everybody, is it possible to use a compound control space using
python?
i've tried but it seems that i can't access the control value in the
propagate function (in the demos compound state objects are accessed using
the as() method, but "as" is a keyword in python and trying to use it as a
method creates a syntax error) is there a way around this problem in python
or i have to switch to c++?
Thanks
Filippo

Re: [ompl-users] Info complex benchmark

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

Hi Luigi,

For this you’d use the ompl::tools::Benchmark::addExperimentParameter <http://ompl.kavrakilab.org/classompl_1_1tools_1_1Benchmark.html#afab48f173edc785ee005301642b1afb1> method for that:

// run a separate benchmark for all start and goal positions
ompl::tools::Benchmark b(simpleSetup, “myBenchmark");
b.addExperimentParameter(“startX", “REAL", std::to_string(startX));
b.addExperimentParameter(“startY", “REAL", std::to_string(startY));
…

PlannerArena has some support for parametrized benchmarks. Give it a try and let me know if you need a different kind of visualization of the result.

Mark



> On Jan 18, 2018, at 7:52 AM, pal...@cs... wrote:
> 
> Hi all,
> 
> One question regarding the ompl::tools::benchmark tool. I would like to have a benchmark where I could vary the start and goal positions. Is that possible? I see that we could vary the planner parameters, but usually start and goals are not considered as such. Any idea on how to do it?
> 
> Thanks!
> 
> Best Regards,
> 
> Luigi

[ompl-users] Info complex benchmark

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

Hi all, 
One question regarding the ompl::tools::benchmark tool. I would like to have a benchmark where I could vary the start and goal positions. Is that possible? I see that we could vary the planner parameters, but usually start and goals are not considered as such. Any idea on how to do it?
Thanks! 
Best Regards, 
Luigi 

Re: [ompl-users] Loading roadmaps

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

Hi Andreas,

You might also want to explore the Thunder planning framework, which loads/saves sparse roadmaps and lazily re-evaluates nodes and edges. See the demo in ompl/demos/ThunderLightning.cpp and the corresponding paper <https://www.cs.rice.edu/~mmoll/publications/coleman2015experience-based-planning-with-sparse.pdf>.

Mark



> On Jan 2, 2018, at 4:51 PM, ahofmann <an...@do...> wrote:
> 
> 
> Hi Mark,
> 
> I am currently interested only in using the PRM type planners.  I would like to sample once to generate a roadmap that
> avoids static obstacles and self collisions.  I would then like to use this roadmap henceforth, but check at planning
> time if any nodes or edges have become occluded by dynamic obstacles.  It seems like the main thing I need for this is
> the ability to save the roadmap after it's been generated (once), and then the ability to load it in future processes.
> 
> It looks like the demo in PlannerData.cpp does something like this.  I'll investigate this further.
> 
> Andreas
> 
> 
> 
> On 2017-12-31 10:55, Mark Moll wrote:
>> Hi Andreas,
>> It may be possible to load planner data in the GUI, but this would
>> then only be used for visualization purposes. There is currently no
>> way to initialize a planner with a saved tree/roadmap. Doing this is
>> non-trivial. The internal planner representation of this data is not
>> standardized. The exported planner data should contain *most* of the
>> information needed to recreate it, but not necessarily all (for
>> example, coverage estimates that are used by ProjEST and KPIECE are
>> not saved).
>> If you are thinking of using this in the context of replanning in
>> dynamic / uncertain environments, you could also consider writing a
>> special sampler class that uses planner data from a previous planning
>> cycle to feed states to the current planning cycle (followed by
>> generating random states if all states from the planner data have been
>> sampled).
>> Mark
>>> On Dec 22, 2017, at 1:18 PM, ahofmann <an...@do...> wrote:
>>> Hi,
>>> I recently installed OMPLapp (on Ubuntu 16.04).  I noticed that it
>>> is possible, from the menu,
>>> to save a PRM generated roadmap, but it does not seem to be possible
>>> to load one.
>>> I checked the code in ompl_app.py, and confirmed that this is the
>>> case;  there is
>>> a function savePlannerData, but no corresponding loadPlannerData.
>>> I also checked PRM.h, and it seems like there is an API for
>>> accessing the roadmap graph
>>> (g_) but not for setting it.
>>> Are there any plans to provide a means for loading a saved roadmap?
>>> Regards,
>>> Andreas Hofmann

Re: [ompl-users] Loading roadmaps

[ahofmann <an...@do...>]

Hi Mark,

I am currently interested only in using the PRM type planners.  I would 
like to sample once to generate a roadmap that
avoids static obstacles and self collisions.  I would then like to use 
this roadmap henceforth, but check at planning
time if any nodes or edges have become occluded by dynamic obstacles.  
It seems like the main thing I need for this is
the ability to save the roadmap after it's been generated (once), and 
then the ability to load it in future processes.

It looks like the demo in PlannerData.cpp does something like this.  
I'll investigate this further.

Andreas



On 2017-12-31 10:55, Mark Moll wrote:
> Hi Andreas,
> 
> It may be possible to load planner data in the GUI, but this would
> then only be used for visualization purposes. There is currently no
> way to initialize a planner with a saved tree/roadmap. Doing this is
> non-trivial. The internal planner representation of this data is not
> standardized. The exported planner data should contain *most* of the
> information needed to recreate it, but not necessarily all (for
> example, coverage estimates that are used by ProjEST and KPIECE are
> not saved).
> 
> If you are thinking of using this in the context of replanning in
> dynamic / uncertain environments, you could also consider writing a
> special sampler class that uses planner data from a previous planning
> cycle to feed states to the current planning cycle (followed by
> generating random states if all states from the planner data have been
> sampled).
> 
> Mark
> 
>> On Dec 22, 2017, at 1:18 PM, ahofmann <an...@do...> wrote:
>> 
>> Hi,
>> 
>> I recently installed OMPLapp (on Ubuntu 16.04).  I noticed that it
>> is possible, from the menu,
>> to save a PRM generated roadmap, but it does not seem to be possible
>> to load one.
>> I checked the code in ompl_app.py, and confirmed that this is the
>> case;  there is
>> a function savePlannerData, but no corresponding loadPlannerData.
>> I also checked PRM.h, and it seems like there is an API for
>> accessing the roadmap graph
>> (g_) but not for setting it.
>> 
>> Are there any plans to provide a means for loading a saved roadmap?
>> 
>> Regards,
>> Andreas Hofmann

Re: [ompl-users] Loading roadmaps

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

Hi Andreas,

It may be possible to load planner data in the GUI, but this would then only be used for visualization purposes. There is currently no way to initialize a planner with a saved tree/roadmap. Doing this is non-trivial. The internal planner representation of this data is not standardized. The exported planner data should contain *most* of the information needed to recreate it, but not necessarily all (for example, coverage estimates that are used by ProjEST and KPIECE are not saved).

If you are thinking of using this in the context of replanning in dynamic / uncertain environments, you could also consider writing a special sampler class that uses planner data from a previous planning cycle to feed states to the current planning cycle (followed by generating random states if all states from the planner data have been sampled).

Mark



> On Dec 22, 2017, at 1:18 PM, ahofmann <an...@do...> wrote:
> 
> 
> Hi,
> 
> I recently installed OMPLapp (on Ubuntu 16.04).  I noticed that it is possible, from the menu,
> to save a PRM generated roadmap, but it does not seem to be possible to load one.
> I checked the code in ompl_app.py, and confirmed that this is the case;  there is
> a function savePlannerData, but no corresponding loadPlannerData.
> I also checked PRM.h, and it seems like there is an API for accessing the roadmap graph
> (g_) but not for setting it.
> 
> Are there any plans to provide a means for loading a saved roadmap?
> 
> Regards,
> Andreas Hofmann

[ompl-users] Loading roadmaps

[ahofmann <an...@do...>]

Hi,

I recently installed OMPLapp (on Ubuntu 16.04).  I noticed that it is 
possible, from the menu,
to save a PRM generated roadmap, but it does not seem to be possible to 
load one.
I checked the code in ompl_app.py, and confirmed that this is the case;  
there is
a function savePlannerData, but no corresponding loadPlannerData.
I also checked PRM.h, and it seems like there is an API for accessing 
the roadmap graph
(g_) but not for setting it.

Are there any plans to provide a means for loading a saved roadmap?

Regards,
Andreas Hofmann

Re: [ompl-users] RRT* - replanning motion

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

Hi Luca,

Whether saving a path vs. saving a tree is better depends on how much the environment is changing, how expensive is to re-check states for collisions, etc. There is no general rule for this.

If recomputing the cost of a state is expensive, you could consider some sort of caching / memoization [1].

Mark

[1] Something along the lines of https://stackoverflow.com/questions/17805969/writing-universal-memoization-function-in-c11 <https://stackoverflow.com/questions/17805969/writing-universal-memoization-function-in-c11> perhaps.

> On Dec 17, 2017, at 3:32 AM, bar...@vi... wrote:
> 
> Hello Mark,
> 
> 
> 
> thanks for the hint and sorry for the late reply.
> 
> So you are suggesting to save the path rather than the tree, right? My goal is to implement a planner that returns a solution as fast as possible. If I follow your suggestion, I will loose information, such the costs, parents and children of the nodes of the tree. I have been trying to save the overall tree to avoid recomputing these things again.
> 
> Do you think that a RRT* algorithm with a modified sampler will be faster than the approach I described? Won't the planner loose too much time recomputing the information about each node?
> 
> In any case, I will try to implement your idea. I'll get back to you as soon as I have something that works.
> 
> 
> 
> Thanks again for the help!
> 
> Luca
> 
>> Il 16 dicembre 2017 alle 0.35 Mark Moll <mm...@ri...> ha scritto:
>> 
>> Hi Luca,
>> 
>> The bookkeeping for re-checking all states generated during a previous planning cycle can be quite expensive. It might be better to preserve just the remaining states of the path that the robot has been executing. The states on this path can be stored inside a new a StateSampler-derived class. This new class will return these states the first number of calls to sample(). Subsequent calls to sample() will return uniform samples as usual. You no need to set a SamplerAllocator <http://ompl.kavrakilab.org/classompl_1_1base_1_1StateSpace.html#aa88e8a85586b93866ef3b2a6fb31c114> to specify a function that will return an instance of this sampler.
>> 
>> Mark
>> 
>> 
>> 
>>> On Dec 15, 2017, at 5:22 AM, bartolomei-luca--- via ompl-users <omp...@li... <mailto:omp...@li...>> wrote:
>>> 
>>> Hello everyone!
>>> 
>>> I am trying to implement a path planning algorithm for a robot that navigates in an unknown environment. The concept is very simple: plan, move and if an obstacle is detected, then re-plan. Everything is implemented in ROS.
>>> 
>>> In order to do so, I am trying to modify the RRT* algorithm. Basically, I want to re-use the existing tree and modify it according to the new incoming information. This issue has already been discussed in the OMPL mailing list, but I would like to explain to you guys my approach. It is different from all the others I have seen.
>>> 
>>> I want to create a "storage" for the current tree. Every time the planner is called:
>>> 
>>> 1) Read storage variable
>>> 
>>> 2) Upload storage in the nn_ variable of the planner
>>> 
>>> 3) Plan
>>> 
>>> 4) Save the new tree in the storage variable
>>> 
>>> Unfortunately it is not working properly. Now I will get into more detail (code-wise) . I have added some marks where the problems happen. They are explained at the bottom of the email.
>>> 
>>> 
>>> 
>>> At the moment, I am saving the tree in a vector --> std::vector<Motion*> tree_storage
>>> 
>>> I have added a temporary storage in the RRT* planner --> std::vector<Motion*>* temp_tree_storage (NOTE: a pointer)
>>> 
>>> temp_tree_storage is needed in order to save the information and "upload" them in the variable nn_  of the planner. I have added the following method in order to save/update the tree:
>>> 
>>> void ompl::geometric::RRTstarModified::setTree(std::vector<Motion*>* currentTree)  // NOTE: get a pointer as input
>>>  {
>>> 
>>>      temp_tree_storage = currentTree;             // set the address where to save the new tree --> problem:(1)
>>> 
>>>      for(int i=0; i<currentTree->size(); ++i) {
>>> 
>>>                nn_->add((*currentTree)[i]);             // upload the new tree in the nn_ variable -----> problem:(2)
>>> 
>>>      }
>>> 
>>> }
>>> 
>>> The "solve" method has also been modified in order to save the new tree:
>>> 
>>> ompl::base::PlannerStatus ompl::geometric::RRTstarModified::solve(const base::PlannerTerminationCondition &ptc)
>>> {
>>> 
>>>         // Solver stuff ....
>>> 
>>>          .......
>>> 
>>>        /// Before the "return"
>>> 
>>>       temp_tree_storage ->clear();
>>>        std::vector<Motion*> list;
>>>        nn_->list(list);                                  // get the new tree
>>>        for(int i=0; i<list.size(); ++i)
>>>                    temp_tree_storage->push_back(list[i]);
>>> 
>>> }
>>> 
>>> Since the information on the space are changing,  I am creating a new planner at every "iteration" (i.e. every time a replanning is needed). This happens in the main class:
>>> 
>>> 
>>> 
>>> ompl::base::PlannerPtr MyPlannerAlgorithm::allocateGlobalPlanner(const ompl::base::SpaceInformationPtr &si)
>>> {
>>>     ompl::geometric::RRTstarModified *rrt_star_planner {new ompl::geometric::RRTstarModified(si)};
>>>     rrt_star_planner->setTree(&currentTree);  // The method described above
>>>     ompl::base::PlannerPtr planner(rrt_star_planner);
>>> 
>>>     return planner;
>>> }
>>> 
>>> There are 2 main problems:
>>> 
>>> (1) The children of some of the motions go crazy -> the information is not saved properly and basically I am reading/saving trash that will make my code crash.
>>> 
>>> (2) When I use: nn_->add((*currentTree)[i]);    the code crashes. I have made sure that nn_.reset and nn_->setDistanceFunction before the nn_->add method is called.
>>> 
>>> 
>>> 
>>> I hope I have explained what's going on clearly. Do you have any suggestion on how to solve the problem? Or do you have any better strategy?
>>> 
>>> 
>>> 
>>> Thanks a lot for the help!
>>> 
>>> Have a nice day,
>>> Luca
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> 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
>> 

Re: [ompl-users] RRT* - replanning motion

[<bar...@vi...>]

Hello Mark,


thanks for the hint and sorry for the late reply.

So you are suggesting to save the path rather than the tree, right? My goal is to implement a planner that returns a solution as fast as possible. If I follow your suggestion, I will loose information, such the costs, parents and children of the nodes of the tree. I have been trying to save the overall tree to avoid recomputing these things again.

Do you think that a RRT* algorithm with a modified sampler will be faster than the approach I described? Won't the planner loose too much time recomputing the information about each node?

In any case, I will try to implement your idea. I'll get back to you as soon as I have something that works.


Thanks again for the help!

Luca

>     Il 16 dicembre 2017 alle 0.35 Mark Moll <mm...@ri...> ha scritto:
> 
>     Hi Luca,
> 
>     The bookkeeping for re-checking all states generated during a previous planning cycle can be quite expensive. It might be better to preserve just the remaining states of the path that the robot has been executing. The states on this path can be stored inside a new a StateSampler-derived class. This new class will return these states the first number of calls to sample(). Subsequent calls to sample() will return uniform samples as usual. You no need to set a SamplerAllocator http://ompl.kavrakilab.org/classompl_1_1base_1_1StateSpace.html#aa88e8a85586b93866ef3b2a6fb31c114  to specify a function that will return an instance of this sampler.
> 
>     Mark
> 
> 
> 
> 
>         > >         On Dec 15, 2017, at 5:22 AM, bartolomei-luca--- via ompl-users <omp...@li... mailto:omp...@li... > wrote:
> > 
> > 
> >         Hello everyone!
> > 
> >         I am trying to implement a path planning algorithm for a robot that navigates in an unknown environment. The concept is very simple: plan, move and if an obstacle is detected, then re-plan. Everything is implemented in ROS.
> > 
> >         In order to do so, I am trying to modify the RRT* algorithm. Basically, I want to re-use the existing tree and modify it according to the new incoming information. This issue has already been discussed in the OMPL mailing list, but I would like to explain to you guys my approach. It is different from all the others I have seen. 
> > 
> >         I want to create a "storage" for the current tree. Every time the planner is called:
> > 
> >         1) Read storage variable
> > 
> >         2) Upload storage in the nn_ variable of the planner
> > 
> >         3) Plan
> > 
> >         4) Save the new tree in the storage variable
> > 
> >         Unfortunately it is not working properly. Now I will get into more detail (code-wise) . I have added some marks where the problems happen. They are explained at the bottom of the email.
> > 
> > 
> >         At the moment, I am saving the tree in a vector --> std::vector<Motion*> tree_storage
> > 
> >         I have added a temporary storage in the RRT* planner --> std::vector<Motion*>* temp_tree_storage (NOTE: a pointer)
> > 
> >         temp_tree_storage is needed in order to save the information and "upload" them in the variable nn_  of the planner. I have added the following method in order to save/update the tree:
> > 
> >             void ompl::geometric::RRTstarModified::setTree(std::vector<Motion*>* currentTree)  // NOTE: get a pointer as input
> >              {
> > 
> >                  temp_tree_storage = currentTree;             // set the address where to save the new tree --> problem:(1)
> > 
> >                  for(int i=0; i<currentTree->size(); ++i) {
> > 
> >                            nn_->add((*currentTree)[i]);             // upload the new tree in the nn_ variable -----> problem:(2)
> > 
> >                  }
> > 
> >             }
> > 
> >         The "solve" method has also been modified in order to save the new tree:
> > 
> >             ompl::base::PlannerStatus ompl::geometric::RRTstarModified::solve(const base::PlannerTerminationCondition &ptc)
> >             {
> > 
> >                     // Solver stuff ....
> > 
> >                      .......
> > 
> >                    /// Before the "return"
> > 
> >                   temp_tree_storage ->clear();
> >                    std::vector<Motion*> list;
> >                    nn_->list(list);                                  // get the new tree
> >                    for(int i=0; i<list.size(); ++i)
> >                                temp_tree_storage->push_back(list[i]);
> > 
> >             }
> > 
> >         Since the information on the space are changing,  I am creating a new planner at every "iteration" (i.e. every time a replanning is needed). This happens in the main class:
> > 
> > 
> >             ompl::base::PlannerPtr MyPlannerAlgorithm::allocateGlobalPlanner(const ompl::base::SpaceInformationPtr &si)
> >             {
> >                 ompl::geometric::RRTstarModified *rrt_star_planner {new ompl::geometric::RRTstarModified(si)};
> >                 rrt_star_planner->setTree(&currentTree);  // The method described above
> >                 ompl::base::PlannerPtr planner(rrt_star_planner);
> > 
> >                 return planner;
> >             }
> > 
> >         There are 2 main problems:
> > 
> >         (1) The children of some of the motions go crazy -> the information is not saved properly and basically I am reading/saving trash that will make my code crash.
> > 
> >         (2) When I use: nn_->add((*currentTree)[i]);    the code crashes. I have made sure that nn_.reset and nn_->setDistanceFunction before the nn_->add method is called.
> > 
> > 
> >         I hope I have explained what's going on clearly. Do you have any suggestion on how to solve the problem? Or do you have any better strategy?
> > 
> > 
> >         Thanks a lot for the help!
> > 
> >         Have a nice day,
> >         Luca
> > 
> > 
> > 
> >         ------------------------------------------------------------------------------
> >         Check out the vibrant tech community on one of the world's most
> >         engaging tech sites,http://Slashdot.org ! http://sdm.link/slashdot_______________________________________________
> >         ompl-users mailing list
> >         omp...@li... mailto:omp...@li...
> >         https://lists.sourceforge.net/lists/listinfo/ompl-users
> > 
> >     > 
> 

Re: [ompl-users] RRT* - replanning motion

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

Hi Luca,

The bookkeeping for re-checking all states generated during a previous planning cycle can be quite expensive. It might be better to preserve just the remaining states of the path that the robot has been executing. The states on this path can be stored inside a new a StateSampler-derived class. This new class will return these states the first number of calls to sample(). Subsequent calls to sample() will return uniform samples as usual. You no need to set a SamplerAllocator <http://ompl.kavrakilab.org/classompl_1_1base_1_1StateSpace.html#aa88e8a85586b93866ef3b2a6fb31c114> to specify a function that will return an instance of this sampler.

Mark



> On Dec 15, 2017, at 5:22 AM, bartolomei-luca--- via ompl-users <omp...@li...> wrote:
> 
> Hello everyone!
> 
> I am trying to implement a path planning algorithm for a robot that navigates in an unknown environment. The concept is very simple: plan, move and if an obstacle is detected, then re-plan. Everything is implemented in ROS.
> 
> In order to do so, I am trying to modify the RRT* algorithm. Basically, I want to re-use the existing tree and modify it according to the new incoming information. This issue has already been discussed in the OMPL mailing list, but I would like to explain to you guys my approach. It is different from all the others I have seen.
> 
> I want to create a "storage" for the current tree. Every time the planner is called:
> 
> 1) Read storage variable
> 
> 2) Upload storage in the nn_ variable of the planner
> 
> 3) Plan
> 
> 4) Save the new tree in the storage variable
> 
> Unfortunately it is not working properly. Now I will get into more detail (code-wise) . I have added some marks where the problems happen. They are explained at the bottom of the email.
> 
> 
> 
> At the moment, I am saving the tree in a vector --> std::vector<Motion*> tree_storage
> 
> I have added a temporary storage in the RRT* planner --> std::vector<Motion*>* temp_tree_storage (NOTE: a pointer)
> 
> temp_tree_storage is needed in order to save the information and "upload" them in the variable nn_  of the planner. I have added the following method in order to save/update the tree:
> 
> void ompl::geometric::RRTstarModified::setTree(std::vector<Motion*>* currentTree)  // NOTE: get a pointer as input
>  {
> 
>      temp_tree_storage = currentTree;             // set the address where to save the new tree --> problem:(1)
> 
>      for(int i=0; i<currentTree->size(); ++i) {
> 
>                nn_->add((*currentTree)[i]);             // upload the new tree in the nn_ variable -----> problem:(2)
> 
>      }
> 
> }
> 
> The "solve" method has also been modified in order to save the new tree:
> 
> ompl::base::PlannerStatus ompl::geometric::RRTstarModified::solve(const base::PlannerTerminationCondition &ptc)
> {
> 
>         // Solver stuff ....
> 
>          .......
> 
>        /// Before the "return"
> 
>       temp_tree_storage ->clear();
>        std::vector<Motion*> list;
>        nn_->list(list);                                  // get the new tree
>        for(int i=0; i<list.size(); ++i)
>                    temp_tree_storage->push_back(list[i]);
> 
> }
> 
> Since the information on the space are changing,  I am creating a new planner at every "iteration" (i.e. every time a replanning is needed). This happens in the main class:
> 
> 
> 
> ompl::base::PlannerPtr MyPlannerAlgorithm::allocateGlobalPlanner(const ompl::base::SpaceInformationPtr &si)
> {
>     ompl::geometric::RRTstarModified *rrt_star_planner {new ompl::geometric::RRTstarModified(si)};
>     rrt_star_planner->setTree(&currentTree);  // The method described above
>     ompl::base::PlannerPtr planner(rrt_star_planner);
> 
>     return planner;
> }
> 
> There are 2 main problems:
> 
> (1) The children of some of the motions go crazy -> the information is not saved properly and basically I am reading/saving trash that will make my code crash.
> 
> (2) When I use: nn_->add((*currentTree)[i]);    the code crashes. I have made sure that nn_.reset and nn_->setDistanceFunction before the nn_->add method is called.
> 
> 
> 
> I hope I have explained what's going on clearly. Do you have any suggestion on how to solve the problem? Or do you have any better strategy?
> 
> 
> 
> Thanks a lot for the help!
> 
> Have a nice day,
> Luca
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 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] RRT* - replanning motion

[<bar...@vi...>]

Hello everyone!

I am trying to implement a path planning algorithm for a robot that navigates in an unknown environment. The concept is very simple: plan, move and if an obstacle is detected, then re-plan. Everything is implemented in ROS.

In order to do so, I am trying to modify the RRT* algorithm. Basically, I want to re-use the existing tree and modify it according to the new incoming information. This issue has already been discussed in the OMPL mailing list, but I would like to explain to you guys my approach. It is different from all the others I have seen. 

I want to create a "storage" for the current tree. Every time the planner is called:

1) Read storage variable

2) Upload storage in the nn_ variable of the planner

3) Plan

4) Save the new tree in the storage variable

Unfortunately it is not working properly. Now I will get into more detail (code-wise) . I have added some marks where the problems happen. They are explained at the bottom of the email.


At the moment, I am saving the tree in a vector --> std::vector<Motion*> tree_storage

I have added a temporary storage in the RRT* planner --> std::vector<Motion*>* temp_tree_storage (NOTE: a pointer)

temp_tree_storage is needed in order to save the information and "upload" them in the variable nn_  of the planner. I have added the following method in order to save/update the tree:

void ompl::geometric::RRTstarModified::setTree(std::vector<Motion*>* currentTree)  // NOTE: get a pointer as input
 {

     temp_tree_storage = currentTree;             // set the address where to save the new tree --> problem:(1)

     for(int i=0; i<currentTree->size(); ++i) {

               nn_->add((*currentTree)[i]);             // upload the new tree in the nn_ variable -----> problem:(2)

     }

}

The "solve" method has also been modified in order to save the new tree:

ompl::base::PlannerStatus ompl::geometric::RRTstarModified::solve(const base::PlannerTerminationCondition &ptc)
{

        // Solver stuff ....

         .......

       /// Before the "return"

      temp_tree_storage ->clear();
       std::vector<Motion*> list;
       nn_->list(list);                                  // get the new tree
       for(int i=0; i<list.size(); ++i)
                   temp_tree_storage->push_back(list[i]);

}

Since the information on the space are changing,  I am creating a new planner at every "iteration" (i.e. every time a replanning is needed). This happens in the main class:


ompl::base::PlannerPtr MyPlannerAlgorithm::allocateGlobalPlanner(const ompl::base::SpaceInformationPtr &si)
{
    ompl::geometric::RRTstarModified *rrt_star_planner {new ompl::geometric::RRTstarModified(si)};
    rrt_star_planner->setTree(&currentTree);  // The method described above
    ompl::base::PlannerPtr planner(rrt_star_planner);

    return planner;
}

There are 2 main problems:

(1) The children of some of the motions go crazy -> the information is not saved properly and basically I am reading/saving trash that will make my code crash.

(2) When I use: nn_->add((*currentTree)[i]);    the code crashes. I have made sure that nn_.reset and nn_->setDistanceFunction before the nn_->add method is called.


I hope I have explained what's going on clearly. Do you have any suggestion on how to solve the problem? Or do you have any better strategy?


Thanks a lot for the help!

Have a nice day,
Luca

Re: [ompl-users] Poor results with basic planning for autonomous car-like robot

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

Hi Henry,

Most of the kinodynamic planning algorithms in OMPL don’t give any optimality guarantees. SST is currently the only one that offers asymptotic near optimality: the more time you give it, the closer it will get to the optimal path (within an approximation factor). Please give that planner a try with a generous time limit and let me know if that works any better.

Also note that the default sampler for kinodynamic planning is just sampling uniformly random controls. For any specific system you can design a better sampler that, given two states, will generate a control that will drive the system from one state towards the other. If you can do this for your system, then the other planners in OMPL should perform much more reasonable paths.

Mark



> On Dec 7, 2017, at 5:12 PM, Henry Tonoyan <he...@ot...> wrote:
> 
> Hi,
> 
> I'm getting very poor results while attempting to use OMPL for a basic autonomous robot with car-like steering. I've installed and used the OMPL app gui and set up a trivial scenario. Screenshots are linked to below. Is there anything I can do to improve the quality of the plans? I was expecting a plan with 2 or 3 turns but instead the robot seems to wander around aimlessly until it hits the goal. I've also tried using all the different planners available in the drop-down menu in the GUI with similar results.
> 
> Screenshots here - https://imgur.com/a/KqglH <https://imgur.com/a/KqglH>
> 
> Any suggestions will be greatly appreciated.
> 
> Thanks!