ompl-users — Users mailing list

[ompl-users] Creating an environment

[Savaş Ö. <sav...@gm...>]

 Hi,

I understood the state space concept and I learned how to solve a path from
start to goal in an empty space.
I want to plan in an environment with walls and obstacles.
How can I create a workspace including objects such as cubicles, spheres or
etc.
I'm not using OMPL App.

Thank you.

Savas

Re: [ompl-users] Basic Geometry for OMPL

[Savaş Ö. <sav...@gm...>]

Hi Mark,

I felt very ashamed for having asked such a simple question when I saw your
answer, thank you for your kindness.
boost::math::constants::pi<double>() didn't solve my case but
0.99 * boost::math::constants::pi<double>()  worked.
King Regards,

Savas


Mark Moll <mm...@ri...>, 20 Şub 2021 Cmt, 00:13 tarihinde şunu yazdı:

> Hi Savaş,
>
> Yaw is measured in radians, so the opposite direction of 0 is pi.
>
> Best,
>
> Mark
>
>
>
> On Feb 19, 2021, at 3:56 AM, Savaş Öztürk <sav...@gm...> wrote:
>
> First things first, I would like to express my deepest gratitude for this
> excellent contribution. OMPL is a great solution for robotics planning.
> But I couldn't find anything about the limits for orientation(rotation)
> parameters. For example, for SE2StateSpace, I couldn't resolve setYaw()
> method's usage so far. What type of parameter (angle, distance, ...) should
> I enter? When I plot the coordinates, I see that yaw is 0 when robots face
> is looking at the right? If I enter an angle like 45 degrees no solution is
> found. I enter the values like 1, -1 and assume the direction.  But I don't
> know how to assign an opposite yaw to zero. If would appreciate if you
> recommend me a guide to understand OMPL Geometry well.
> Thanks in advance.
> Savaş Öztürk
>
> _______________________________________________
> ompl-users mailing list
> omp...@li...
> https://lists.sourceforge.net/lists/listinfo/ompl-users
>
>
>

Re: [ompl-users] Basic Geometry for OMPL

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

Hi Savaş,

Yaw is measured in radians, so the opposite direction of 0 is pi.

Best,

Mark



> On Feb 19, 2021, at 3:56 AM, Savaş Öztürk <sav...@gm...> wrote:
> 
> First things first, I would like to express my deepest gratitude for this excellent contribution. OMPL is a great solution for robotics planning. 
> But I couldn't find anything about the limits for orientation(rotation) parameters. For example, for SE2StateSpace, I couldn't resolve setYaw() method's usage so far. What type of parameter (angle, distance, ...) should I enter? When I plot the coordinates, I see that yaw is 0 when robots face is looking at the right? If I enter an angle like 45 degrees no solution is found. I enter the values like 1, -1 and assume the direction.  But I don't know how to assign an opposite yaw to zero. If would appreciate if you recommend me a guide to understand OMPL Geometry well. 
> Thanks in advance. 
> Savaş Öztürk
> 
> _______________________________________________
> ompl-users mailing list
> omp...@li...
> https://lists.sourceforge.net/lists/listinfo/ompl-users

[ompl-users] Basic Geometry for OMPL

[Savaş Ö. <sav...@gm...>]

First things first, I would like to express my deepest gratitude for this
excellent contribution. OMPL is a great solution for robotics planning.
But I couldn't find anything about the limits for orientation(rotation)
parameters. For example, for SE2StateSpace, I couldn't resolve setYaw()
method's usage so far. What type of parameter (angle, distance, ...) should
I enter? When I plot the coordinates, I see that yaw is 0 when robots face
is looking at the right? If I enter an angle like 45 degrees no solution is
found. I enter the values like 1, -1 and assume the direction.  But I don't
know how to assign an opposite yaw to zero. If would appreciate if you
recommend me a guide to understand OMPL Geometry well.
Thanks in advance.
Savaş Öztürk

[ompl-users] getting controls out of planner data in python

[Peter M. <mit...@gm...>]

I'm having trouble getting control info in python. I'm using a oc.RRT and
getting the planner data by:

planner_data = ob.PlannerData(si)
rrt.getPlannerData(planner_data)

which works, but from there I cannot figure out how to get the controls. I
know I should call getControls() on a control::PlannerDataEdgeControl but I
can't figure out how to get that. Also, hasControls returns False. I can
also see that the bindings for control::PlannerData and
control::PlannerDataEdgeControl are not being generated, not sure why
though, since control::PlannerDataEdgeStorage is

Might I get help on making the appropriate changes to get this work? Thanks!

Re: [ompl-users] Removing vertices from PRM graph

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

Hadar,

What you want sounds very similar to using LazyPRM initialized with saved PlannerData. The idea is that you generate a roadmap/graph with any planner, extract the PlannerData (optional save and load to/from disk), and construct a LazyPRM instance with the PlannerData as argument.

The mutex is used exactly so you *can* use multiple threads safely. You need to be careful to remove each vertex/edge only once and make sure that no vertex/edge is accessed by other threads as it is being removed.

Best,

Mark



> On Jan 6, 2021, at 9:55 AM, hadar sinvani <had...@gm...> wrote:
> 
> Hi Mark,
> 
> Thank you for your quick reply.
> 
> As you suggested, I will look through the boost graph library API for the relevant functions and write this method by myself.
> 
> I intend to iterate through the vertices data structure and to check again every vertex with IsValid   (Is Valid will be different, of course, from the IsValid I used during roadmap construction).
> 
> According to the returned value, the method will keep/remove the examined vertex and its edges.
> 
> I would appreciate your advice regarding the function I intend to write.
> 
> In PRM implementation, I saw you use mutex every time you add a milestone or an edge.  Does this mean that my function cannot run multiple threads so that each thread will iterate through different part of the vertices data structure?
> 
> Best and a happy new year,
> 
> Hadar
> 
> 
> 
> 
> 
> On Wed, Jan 6, 2021, 01:16 Mark Moll <mm...@ri... <mailto:mm...@ri...>> wrote:
> Hi Hadar,
> 
> There is no method for this at the moment. You need to write your own method that will call Boost.Graph functions to remove specific vertices and any incident edges.
> 
> Best,
> 
> Mark
> 
> 
> 
>> On Jan 5, 2021, at 7:25 AM, hadar sinvani <had...@gm... <mailto:had...@gm...>> wrote:
>> 
>> Hello,
>> 
>> I'm using the geometric prm planner.
>> 
>> At first, the constructRoadmap function is being called once, following several calls to solve and clearQuery functions. 
>> 
>> I would also like to update my graph between calls and to remove specific vertices, therefore the clear function that clears ALL internal data structure is not a good option for me…
>> 
>> Is there a function that iterates through the vertices data structure and removes specific vertices from the graph?
>> 
>> Best,
>> 
>> Hadar
>> 
>> _______________________________________________
>> 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] Removing vertices from PRM graph

[hadar s. <had...@gm...>]

Hi Mark,

Thank you for your quick reply.

As you suggested, I will look through the boost graph library API for the
relevant functions and write this method by myself.

I intend to iterate through the vertices data structure and to check again
every vertex with IsValid   (Is Valid will be different, of course, from
the IsValid I used during roadmap construction).

According to the returned value, the method will keep/remove the examined
vertex and its edges.

I would appreciate your advice regarding the function I intend to write.

In PRM implementation, I saw you use mutex every time you add a milestone
or an edge.  Does this mean that my function cannot run multiple threads so
that each thread will iterate through different part of the vertices data
structure?

Best and a happy new year,

Hadar




On Wed, Jan 6, 2021, 01:16 Mark Moll <mm...@ri...> wrote:

> Hi Hadar,
>
> There is no method for this at the moment. You need to write your own
> method that will call Boost.Graph functions to remove specific vertices and
> any incident edges.
>
> Best,
>
> Mark
>
>
>
> On Jan 5, 2021, at 7:25 AM, hadar sinvani <had...@gm...> wrote:
>
> Hello,
>
> I'm using the geometric prm planner.
>
> At first, the constructRoadmap function is being called once, following
> several calls to solve and clearQuery functions.
>
> I would also like to update my graph between calls and to remove specific
> vertices, therefore the clear function that clears ALL internal data
> structure is not a good option for me…
>
> Is there a function that iterates through the vertices data structure and
> removes specific vertices from the graph?
>
> Best,
>
> Hadar
> _______________________________________________
> ompl-users mailing list
> omp...@li...
> https://lists.sourceforge.net/lists/listinfo/ompl-users
>
>
>

Re: [ompl-users] Removing vertices from PRM graph

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

Hi Hadar,

There is no method for this at the moment. You need to write your own method that will call Boost.Graph functions to remove specific vertices and any incident edges.

Best,

Mark



> On Jan 5, 2021, at 7:25 AM, hadar sinvani <had...@gm...> wrote:
> 
> Hello,
> 
> I'm using the geometric prm planner.
> 
> At first, the constructRoadmap function is being called once, following several calls to solve and clearQuery functions. 
> 
> I would also like to update my graph between calls and to remove specific vertices, therefore the clear function that clears ALL internal data structure is not a good option for me…
> 
> Is there a function that iterates through the vertices data structure and removes specific vertices from the graph?
> 
> Best,
> 
> Hadar
> 
> _______________________________________________
> ompl-users mailing list
> omp...@li...
> https://lists.sourceforge.net/lists/listinfo/ompl-users

[ompl-users] Removing vertices from PRM graph

[hadar s. <had...@gm...>]

Hello,

I'm using the geometric prm planner.

At first, the constructRoadmap function is being called once, following
several calls to solve and clearQuery functions.

I would also like to update my graph between calls and to remove specific
vertices, therefore the clear function that clears ALL internal data
structure is not a good option for me…

Is there a function that iterates through the vertices data structure and
removes specific vertices from the graph?

Best,

Hadar

[ompl-users] Some issues building the Debian package

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

Hi ompl-devs,


I would like to comments some issues I have found in the ompl code:

1) I have to disable tests. There's one test that fails:

Running 6 test cases...
Error:   Failed to load PlannerData: input stream error
         at line 140 in
/build/ompl-1.5.1+ds1/src/ompl/base/src/PlannerDataStorage.cpp
/build/ompl-1.5.1+ds1/tests/base/planner_data.cpp(531): error: in
"Serialization": check data2.numEdges() == num_edges_to_add has failed
[6084 != 10000]
/build/ompl-1.5.1+ds1/tests/base/planner_data.cpp(557): fatal error: in
"Serialization": critical check neighbors.size() == neighbors2.size()
has failed [10 != 1]

*** 2 failures are detected in the test module "PlannerData"


Could you check it?

2) file-references-package-build-path

This means that in some part of the binary, the path of the files that
are using to build the library is used. This means that the library
fails with reprotest. I think that it comes with the macro OMPL_DEBUG.

Can be the fullpath of the file not hardcoded?

3) lintian has detected some spell errors. Could you fix them?

usr/lib/x86_64-linux-gnu/libompl.so.1.5.1 Unknow Unknown
usr/lib/x86_64-linux-gnu/libompl.so.1.5.1 enought enough
usr/lib/x86_64-linux-gnu/libompl.so.1.5.1 lengH length
usr/lib/x86_64-linux-gnu/libompl.so.1.5.1 verticies vertices

4) I have found some errors when the ompl-demos is installed. In the
CMakeLists of demo directory you use:

install_python function

that adapt the shebang using the PYTHON_EXEC info. However, you install
Koules and VFRRT directories, where there are Python scripts and you
don't change the shebang.

5) I did a patch for the flann libraries. Could you incorporated it?

https://salsa.debian.org/science-team/ompl/-/blob/master/debian/patches/0002-Added-FLANN_LIBRARIES-dependency.patch


In any case, thanks for this great library.

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 State Validity Issue

[Bruce T <bru...@gm...>]

Hi Mark,

Thank you for your recommendations. I was working on comparing different
algorithms on 2d grid. Looks like I'll have to look into making the
obstacle squares bigger.

Thank you,
Bruce

On Tue, Oct 13, 2020 at 9:32 PM Mark Moll <mm...@ri...> wrote:

> Hi Bruce,
>
> For searching a discrete 2D grid, sampling from a 2D continuous space is
> probably not the most efficient way to find a path. You could probably use
> A*. Nevertheless, thickening the obstacles (e.g., by making each obstacle
> square slightly larger than a grid square) would probably fix the issue you
> are seeing.
>
> Best,
>
> Mark
>
>
>
> On Oct 12, 2020, at 10:35 PM, Bruce T <bru...@gm...> wrote:
>
> Hi Mark,
>
> Hope all is well.
>
> I'm quite new to path planning and have been working on 2D path planning
> on grid maps in python. I ran into some issues with state sampling. For
> most of the maps and runs, the implementation works fine. (I used
> RealVectorStateSpace(2)) But for some maps, like the ones attached, the
> path sometimes cuts through the corner and jumps over the obstacles. (top
> left corner on the bottom of the 2nd top black wall) Is there a way to fix
> this issue? I was thinking maybe there's a way to "thicken" the edges
> between the nodes when sampling?
>
> Thank you in advance,
> Bruce
> <Screenshot from 2020-10-13 01-18-51.png><Screenshot from 2020-10-13
> 01-19-32.png>_______________________________________________
> ompl-users mailing list
> omp...@li...
> https://lists.sourceforge.net/lists/listinfo/ompl-users
>
>
>

Re: [ompl-users] OMPL State Validity Issue

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

Hi Bruce,

For searching a discrete 2D grid, sampling from a 2D continuous space is probably not the most efficient way to find a path. You could probably use A*. Nevertheless, thickening the obstacles (e.g., by making each obstacle square slightly larger than a grid square) would probably fix the issue you are seeing.

Best,

Mark



> On Oct 12, 2020, at 10:35 PM, Bruce T <bru...@gm...> wrote:
> 
> Hi Mark, 
> 
> Hope all is well. 
> 
> I'm quite new to path planning and have been working on 2D path planning on grid maps in python. I ran into some issues with state sampling. For most of the maps and runs, the implementation works fine. (I used RealVectorStateSpace(2)) But for some maps, like the ones attached, the path sometimes cuts through the corner and jumps over the obstacles. (top left corner on the bottom of the 2nd top black wall) Is there a way to fix this issue? I was thinking maybe there's a way to "thicken" the edges between the nodes when sampling? 
> 
> Thank you in advance,
> Bruce 
> <Screenshot from 2020-10-13 01-18-51.png><Screenshot from 2020-10-13 01-19-32.png>_______________________________________________
> ompl-users mailing list
> omp...@li...
> https://lists.sourceforge.net/lists/listinfo/ompl-users

[ompl-users] OMPL State Validity Issue

[Bruce T <bru...@gm...>]

Hi Mark,

Hope all is well.

I'm quite new to path planning and have been working on 2D path planning on
grid maps in python. I ran into some issues with state sampling. For most
of the maps and runs, the implementation works fine. (I used
RealVectorStateSpace(2)) But for some maps, like the ones attached, the
path sometimes cuts through the corner and jumps over the obstacles. (top
left corner on the bottom of the 2nd top black wall) Is there a way to fix
this issue? I was thinking maybe there's a way to "thicken" the edges
between the nodes when sampling?

Thank you in advance,
Bruce

[ompl-users] Thunder framework in OMPL

[Fahad I. <fi...@an...>]

Hello all,

I am experimenting with the Thunder planner in OMPL. It either successfully
finds a plan or quickly fails with the message "RetrieveRepair::solve() No
nearest start or goal found". In the code I don't see any call to the
"ThunderRetrieveRepair::repairPath" function which presumably would run a
repair planner like RRTC to find a path. Am I missing something?

Best,
Fahad

Re: [ompl-users] (no subject)

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

Hi Hadar,

No, this is not done currently. Normally, milestones are created through random sampling, which means that the probability that two milestones are the same is infinitesimally small. To check wether two states are *almost* the same, you would have to query the nearest neighbor data structure for each milestone that is added. This is an O(log n) operation. For most applications this extra overhead is not worth it.

Best,

Mark



> On Jul 27, 2020, at 3:30 AM, hadar sinvani <had...@gm...> wrote:
> 
> Hi,
> 
> I'm using the prm planner in a real vector state space.
> 
> Is the graph tested before adding a new state as a milestone in order to verify that the added state does not already exist in the graph?
> 
> Best, Hadar
> 
> _______________________________________________
> ompl-users mailing list
> omp...@li...
> https://lists.sourceforge.net/lists/listinfo/ompl-users

[ompl-users] (no subject)

[hadar s. <had...@gm...>]

Hi,

I'm using the prm planner in a real vector state space.

Is the graph tested before adding a new state as a milestone in order to
verify that the added state does not already exist in the graph?

Best, Hadar

Re: [ompl-users] OMPL - Registering Projection

[Bruce T <bru...@gm...>]

Hi Mark,

Thank you very much for the help, I understand what the mistakes were now.

Thank you,
Bruce

On Tue, Jul 7, 2020 at 11:30 AM Mark Moll <mm...@ri...> wrote:

> Bruce,
>
> It appears the python bindings don’t correctly handle the defaultCellSizes
> method. You can work around it by calling setCellSizes. It’s easiest to
> register your projection as the default projection so that you don’t have
> to call planner.setProjectionEvaluator. Note that the last method requires
> a string argument (the name of the projection), not a ProjectionEvaluator
> object.
>
> Best,
>
> Mark
>
>
> On Jul 3, 2020, at 1:45 PM, Bruce T <bru...@gm...> wrote:
>
> Hi Mark,
>
> Thank you for your quick response and help. I see in your modified version
> that there is now a new projection for the space with cell sizes inferred
> by sampling. I have a follow up question. I tried to use the following
> inside the class to define
> the deafultcellsizes, but it didn't change the cell sizes. How should I
> redefine the cellsizes and choose that new projection for planning. Thank
> you again
>
> Bruce
>
> def defaultCellSizes(self):
> self.cellSizes_ = list2vec([1.0, 1.0])
>
> On Fri, Jul 3, 2020 at 1:29 AM Mark Moll <mm...@ri...> wrote:
>
>> Bruce,
>>
>> Your projection didn’t define some pure virtual methods. This modified
>> version works for me:
>>
>> Best,
>>
>> Mark
>>
>>
>>
>> On Jul 2, 2020, at 10:15 PM, Bruce T <bru...@gm...> wrote:
>>
>> Hi Mark,
>>
>> Hope all is well.
>>
>> I'm looking to generate paths in OMPL for grids with 1x1 cell size. From
>> what I've read, I believe I would have to change the cell size by planning
>> with a ProjectionEvaluator for my state space. I registered the projection
>> for the space and planner and the following type error keeps occuring when
>> I have any methods related to registering or setting up projections.
>>
>> <Screenshot from 2020-07-03 01-03-28.png>
>>
>> I've attached my python code, I modified one of your demos. I've been
>> stuck on this for a while and any advice would help a lot. Thank you in
>> advance.
>>
>> Bruce
>> <OMPLquestion.py>_______________________________________________
>> ompl-users mailing list
>> omp...@li...
>> https://lists.sourceforge.net/lists/listinfo/ompl-users
>>
>>
>>
>

Re: [ompl-users] OMPL - Registering Projection

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

Bruce,

It appears the python bindings don’t correctly handle the defaultCellSizes method. You can work around it by calling setCellSizes. It’s easiest to register your projection as the default projection so that you don’t have to call planner.setProjectionEvaluator. Note that the last method requires a string argument (the name of the projection), not a ProjectionEvaluator object.

Best,

Mark



> On Jul 3, 2020, at 1:45 PM, Bruce T <bru...@gm...> wrote:
> 
> Hi Mark,
> 
> Thank you for your quick response and help. I see in your modified version that there is now a new projection for the space with cell sizes inferred by sampling. I have a follow up question. I tried to use the following inside the class to define 
> the deafultcellsizes, but it didn't change the cell sizes. How should I redefine the cellsizes and choose that new projection for planning. Thank you again
> 
> Bruce 
> 
>     def defaultCellSizes(self):
>         self.cellSizes_ = list2vec([1.0, 1.0])
> 
> On Fri, Jul 3, 2020 at 1:29 AM Mark Moll <mm...@ri... <mailto:mm...@ri...>> wrote:
> Bruce,
> 
> Your projection didn’t define some pure virtual methods. This modified version works for me:
> 
> Best,
> 
> Mark
> 
> 
> 
>> On Jul 2, 2020, at 10:15 PM, Bruce T <bru...@gm... <mailto:bru...@gm...>> wrote:
>> 
>> Hi Mark,
>> 
>> Hope all is well. 
>> 
>> I'm looking to generate paths in OMPL for grids with 1x1 cell size. From what I've read, I believe I would have to change the cell size by planning with a ProjectionEvaluator for my state space. I registered the projection for the space and planner and the following type error keeps occuring when I have any methods related to registering or setting up projections.  
>> 
>> <Screenshot from 2020-07-03 01-03-28.png>
>> 
>> I've attached my python code, I modified one of your demos. I've been stuck on this for a while and any advice would help a lot. Thank you in advance.
>> 
>> Bruce 
>> <OMPLquestion.py>_______________________________________________
>> 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] OMPL - Registering Projection

[Bruce T <bru...@gm...>]

Hi Mark,

Thank you for your quick response and help. I see in your modified version
that there is now a new projection for the space with cell sizes inferred
by sampling. I have a follow up question. I tried to use the following
inside the class to define
the deafultcellsizes, but it didn't change the cell sizes. How should I
redefine the cellsizes and choose that new projection for planning. Thank
you again

Bruce

def defaultCellSizes(self):
self.cellSizes_ = list2vec([1.0, 1.0])

On Fri, Jul 3, 2020 at 1:29 AM Mark Moll <mm...@ri...> wrote:

> Bruce,
>
> Your projection didn’t define some pure virtual methods. This modified
> version works for me:
>
> Best,
>
> Mark
>
>
>
> On Jul 2, 2020, at 10:15 PM, Bruce T <bru...@gm...> wrote:
>
> Hi Mark,
>
> Hope all is well.
>
> I'm looking to generate paths in OMPL for grids with 1x1 cell size. From
> what I've read, I believe I would have to change the cell size by planning
> with a ProjectionEvaluator for my state space. I registered the projection
> for the space and planner and the following type error keeps occuring when
> I have any methods related to registering or setting up projections.
>
> <Screenshot from 2020-07-03 01-03-28.png>
>
> I've attached my python code, I modified one of your demos. I've been
> stuck on this for a while and any advice would help a lot. Thank you in
> advance.
>
> Bruce
> <OMPLquestion.py>_______________________________________________
> ompl-users mailing list
> omp...@li...
> https://lists.sourceforge.net/lists/listinfo/ompl-users
>
>
>

Re: [ompl-users] OMPL - Registering Projection

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

Bruce,

Your projection didn’t define some pure virtual methods. This modified version works for me:

Best,

Mark



> On Jul 2, 2020, at 10:15 PM, Bruce T <bru...@gm...> wrote:
> 
> Hi Mark,
> 
> Hope all is well. 
> 
> I'm looking to generate paths in OMPL for grids with 1x1 cell size. From what I've read, I believe I would have to change the cell size by planning with a ProjectionEvaluator for my state space. I registered the projection for the space and planner and the following type error keeps occuring when I have any methods related to registering or setting up projections.  
> 
> <Screenshot from 2020-07-03 01-03-28.png>
> 
> I've attached my python code, I modified one of your demos. I've been stuck on this for a while and any advice would help a lot. Thank you in advance.
> 
> Bruce 
> <OMPLquestion.py>_______________________________________________
> ompl-users mailing list
> omp...@li...
> https://lists.sourceforge.net/lists/listinfo/ompl-users

[ompl-users] Fwd: OMPL - Registering Projection

[Bruce T <bru...@gm...>]

Hi Mark,

Hope all is well.

I'm looking to generate paths in OMPL for grids with 1x1 cell size. From
what I've read, I believe I would have to change the cell size by planning
with a ProjectionEvaluator for my state space. I registered the projection
for the space and planner and the following type error keeps occuring when
I have any methods related to registering or setting up projections.

[image: Screenshot from 2020-07-03 01-03-28.png]

I've attached my python code, I modified one of your demos. I've been stuck
on this for a while and any advice would help a lot. Thank you in advance.

Bruce

Re: [ompl-users] Edge checking in control based planners

[Peter M. <mit...@gm...>]

Hi mark, my apologies for not responding to this. In fact that does not do
what I want, I have a quite unusual planning problem where the validity of
an edge cannot be determined by discretizing and checking individual
states. But it was not a problem to implement this within OMPL.

On Sun, Dec 8, 2019 at 6:26 PM Mark Moll <mm...@ri...> wrote:

> Hi Peter,
>
> There is no notion of a motion validator for kinodynamic planning on OMPL.
> Instead, the state validator is called after each call to the state
> propagator. The propagation step size should thus be sufficiently small so
> that the max. possible change in position is roughly equal to the collision
> checking resolution. Don’t confuse propagation step size with integration
> step size, though. Integration step size is often on the order of magnitude
> of .01 or smaller. The propagation step size can often be safely set to be
> an order of magnitude larger. The SpaceInformation::propagateWhileValid
> methods take as one of their arguments the max. number of steps (i.e.,
> calls to the state propagator) that will be taken. It seems like calling
> that method should give you what you want, no?
>
> Best,
>
> Mark
>
>
>
> On Nov 22, 2019, at 7:47 AM, Peter Mitrano <mit...@gm...> wrote:
>
> Hi Mark & others, I'm wondering if there is a hook for implementing
> continuous edge checking in the control based planners. Specifically, I
> want to validate a (x, u, x') tuple. A motion validator only validates (x,
> x') and state validity is of course just (x). At the moment, I am
> implementing this by setting the state to be infinity inside my
> propagate function, and using a state validity checker to check that
> result. I feel a much cleaner method would be to make propagate return bool
> instead of void, and then propagateWhileValid would check that in addition
> to a stateValidity checker. Is there a better way to do it?
>
> Thank you,
> -Peter Mitrano
> _______________________________________________
> ompl-users mailing list
> omp...@li...
> https://lists.sourceforge.net/lists/listinfo/ompl-users
>
>
>

Re: [ompl-users] Straight line (in config space) path?

[Lydia K. <ka...@ri...>]

Thanks Mark. I would not recommend that all planners are changed for this. This is something to check before running a planner. 

LK 

> On Jun 24, 2020, at 10:54 AM, Mark Moll <mm...@ri...> wrote:
> 
> You can (sort of) do this in OMPL without having to modify each planner, although it’s a little convoluted:
> 1. Create an instance of AnytimePathShortening (APS)
> 2. Add an instance of your preferred planner to APS
> 3. Create a new “planner” that only tries straight line interpolation and add an instance to APS
> 4. Set the termination condition to be exactSolnPlannerTerminationCondition <http://ompl.kavrakilab.org/namespaceompl_1_1base.html#a71261936b94c44c59a9f26168b30ea1f>(…) (to make sure APS stops when the first solution is found.
> 
> Best,
> 
> Mark
> 
> 
> 
>> On Jun 23, 2020, at 8:01 AM, Patrick Beeson <bee...@gm... <mailto:bee...@gm...>> wrote:
>> 
>> In using OMPL via MoveIt!, I'm noticing that OMPL often does a whole lot of work to plan even when there's a straight line in configuration space from the start to the goal.  So it'll find a solution of let's say 6-10 points then that gets shortened down to 2, the start and goal.
>> 
>> In asking about just checking the 2 point plan of start/goal for collisions in MoveIt! (https://answers.ros.org/question/355617/can-moveit-first-check-shortest-path-before-planning/ <https://answers.ros.org/question/355617/can-moveit-first-check-shortest-path-before-planning/>), the short answer was "your planner needs to support it".  So, now I'm asking here, does OMPL support this functionality as an option prior to running plans, and is this exposed via the MoveIt! API into OMPL?  If so, I'm missing where this is documented.  If not, is there a viable solution to do this in OMPL?
>> _______________________________________________
>> ompl-users mailing list
>> omp...@li... <mailto:omp...@li...>
>> https://lists.sourceforge.net/lists/listinfo/ompl-users
> 
> _______________________________________________
> ompl-users mailing list
> omp...@li...
> https://lists.sourceforge.net/lists/listinfo/ompl-users

Re: [ompl-users] Straight line (in config space) path?

[Patrick B. <bee...@gm...>]

I completely understand you Lydia.  I also started a thread for MoveIt!
that it might be useful to add this kind of check as an pre-planning
Adapter, that lies outside OMPL.  The funny thing is that some of the
MoveIt! maintainers say the exact opposite: "This is something you should
do in your planner".  So I'm searching for the best solution.

I like Mark's idea, though. I can see potentially using Mark's solution
even for the related issue I brought up earlier about the PRM-derivatives
always using the full amount of time to plan.  As I had remarked earlier,
it would be nice for those to have a "switch" from exploration to straight
exploitation of the roadmap, providing the first solution found in the
roadmap without expanding it more.  Instead of mucking up PRM and its
derivatives to support this, it might be best to write alternative planners
that do this and simply run the two side-by-side, where one continues to
grow the roadmap in the background and the other uses a static roadmap.
Though doing this may involve copying roadmaps, which I've seen get pretty
large in my playing around with the latest LazyPRM* that allows roadmap
loading.

Thanks for the help folks!

On Wed, Jun 24, 2020 at 11:52 AM Lydia Kavraki <ka...@ri...> wrote:

> Thanks Mark. I would not recommend that all planners are changed for this.
> This is something to check before running a planner.
>
> LK
>
> On Jun 24, 2020, at 10:54 AM, Mark Moll <mm...@ri...> wrote:
>
> You can (sort of) do this in OMPL without having to modify each planner,
> although it’s a little convoluted:
> 1. Create an instance of AnytimePathShortening (APS)
> 2. Add an instance of your preferred planner to APS
> 3. Create a new “planner” that only tries straight line interpolation and
> add an instance to APS
> 4. Set the termination condition to be
> exactSolnPlannerTerminationCondition
> <http://ompl.kavrakilab.org/namespaceompl_1_1base.html#a71261936b94c44c59a9f26168b30ea1f>(…)
> (to make sure APS stops when the first solution is found.
>
> Best,
>
> Mark
>
>
>
> On Jun 23, 2020, at 8:01 AM, Patrick Beeson <bee...@gm...> wrote:
>
> In using OMPL via MoveIt!, I'm noticing that OMPL often does a whole lot
> of work to plan even when there's a straight line in configuration space
> from the start to the goal.  So it'll find a solution of let's say 6-10
> points then that gets shortened down to 2, the start and goal.
>
> In asking about just checking the 2 point plan of start/goal for
> collisions in MoveIt! (
> https://answers.ros.org/question/355617/can-moveit-first-check-shortest-path-before-planning/),
> the short answer was "your planner needs to support it".  So, now I'm
> asking here, does OMPL support this functionality as an option prior to
> running plans, and is this exposed via the MoveIt! API into OMPL?  If so,
> I'm missing where this is documented.  If not, is there a viable solution
> to do this in OMPL?
> _______________________________________________
> ompl-users mailing list
> omp...@li...
> https://lists.sourceforge.net/lists/listinfo/ompl-users
>
>
> _______________________________________________
> ompl-users mailing list
> omp...@li...
> https://lists.sourceforge.net/lists/listinfo/ompl-users
>
>
>

Re: [ompl-users] Straight line (in config space) path?

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

You can (sort of) do this in OMPL without having to modify each planner, although it’s a little convoluted:
1. Create an instance of AnytimePathShortening (APS)
2. Add an instance of your preferred planner to APS
3. Create a new “planner” that only tries straight line interpolation and add an instance to APS
4. Set the termination condition to be exactSolnPlannerTerminationCondition <http://ompl.kavrakilab.org/namespaceompl_1_1base.html#a71261936b94c44c59a9f26168b30ea1f>(…) (to make sure APS stops when the first solution is found.

Best,

Mark



> On Jun 23, 2020, at 8:01 AM, Patrick Beeson <bee...@gm...> wrote:
> 
> In using OMPL via MoveIt!, I'm noticing that OMPL often does a whole lot of work to plan even when there's a straight line in configuration space from the start to the goal.  So it'll find a solution of let's say 6-10 points then that gets shortened down to 2, the start and goal.
> 
> In asking about just checking the 2 point plan of start/goal for collisions in MoveIt! (https://answers.ros.org/question/355617/can-moveit-first-check-shortest-path-before-planning/ <https://answers.ros.org/question/355617/can-moveit-first-check-shortest-path-before-planning/>), the short answer was "your planner needs to support it".  So, now I'm asking here, does OMPL support this functionality as an option prior to running plans, and is this exposed via the MoveIt! API into OMPL?  If so, I'm missing where this is documented.  If not, is there a viable solution to do this in OMPL?
> _______________________________________________
> ompl-users mailing list
> omp...@li...
> https://lists.sourceforge.net/lists/listinfo/ompl-users