ompl/ompl

The Open Motion Planning Library (OMPL)

The Open Motion Planning Library (OMPL)

Continuous Integration Status

Installation

Visit the OMPL installation page for detailed installation instructions.

OMPL has the following required dependencies:

• Boost (version 1.58 or higher)
• CMake (version 3.12 or higher)
• Eigen (version 3.3 or higher)

The following dependencies are optional:

• Py++ (needed to generate Python bindings)
• Doxygen (needed to create a local copy of the documentation at https://ompl.kavrakilab.org/core)
• Flann (FLANN can be used for nearest neighbor queries by OMPL)
• Spot (Used for constructing finite automata from LTL formulae.)

Once dependencies are installed, you can build OMPL on Linux, macOS, and MS Windows. Go to the top-level directory of OMPL and type the following commands:

mkdir -p build/Release
cd build/Release
cmake ../..
# next step is optional
make -j 4 update_bindings # if you want Python bindings
make -j 4 # replace "4" with the number of cores on your machine

ompl's Issues

Problem with OMPL installation

Original report by Usman (Bitbucket: usman1989, GitHub: usman1989).

---

Hi,
I am trying to install OMPL and when I try to cmake, the following error appears (last portion of cmake output is provided here):

-- Installed version of flann is too old. Version 1.8.3 or above required.
-- checking for module 'ccd=1.4'
--   found ccd, version 1.4
-- checking for module 'fcl>=0.2.7'
--   package 'fcl>=0.2.7' not found
-- FCL library not found.  Will download and compile.
-- checking for module 'assimp'
--   found assimp, version 2.0
-- Found assimp: assimp 
CMake Error: File /home/mani/installed\ packages/omplapp-0.12.2-Source/ompl/src/ompl/config.h.in does not exist.
CMake Error at ompl/src/ompl/CMakeLists.txt:6 (configure_file):
  configure_file Problem configuring file



CMake Error: File /home/mani/installed\ packages/omplapp-0.12.2-Source/ompl/tests/resources/config.h.in does not exist.
CMake Error at ompl/tests/CMakeLists.txt:7 (configure_file):
  configure_file Problem configuring file



CMake Error: File /home/mani/installed\ packages/omplapp-0.12.2-Source/ompl/tests/BoostTestTeamCityReporter.h.in does not exist.
CMake Error at ompl/tests/CMakeLists.txt:12 (configure_file):
  configure_file Problem configuring file


-- Configuring incomplete, errors occurred!

The problem is that Cmake is looking for a file "config.h.in" and unable to find it however this file exists in the location where Cmake is looking for it. Cmake also shows that FCL is not available. The very same thing happens when I try to install FCL.

Please tell me how can I resolve this issue.

Regards.

libompl.dll

Original report by Anonymous.

---

Good evening

For two week of hard work I tried to build and compile ompl, I did some modification in the cmake files, and recently I m stuck with one erreur that I couldn't solve,

During compiling, I have this message:

"CMake Error at ompl/src/ompl/cmake_install.cmake:51 (FILE):
  file INSTALL cannot find "C:/omplapp/lib/libompl.dll".
Call Stack (most recent call first):
  ompl/src/cmake_install.cmake:40 (INCLUDE)
  cmake_install.cmake:49 (INCLUDE)"

I looked ompl/src/cmake_install.cmake and at ompl/src/ompl/CMakeList, but I coudn't find a bug at the code source, I looked at C:/omplapp/lib/lib and actually I did not find the library file

Please help me, I did already spend two weeks, and time is running I m in a internship so I must progress.

Best regards
technical data :
Os vista family edition
Compiler "MinGW"
cmake2.8.10
CMD command prompt

Something wrong when typing python ompl_app.py

Original report by fengguozhihen (Bitbucket: fengguozhihen, ).

---

After installed the latest released ompl at ubuntu 12.04, I type python ompl_app.py at the command line and the reply is like this:

#!
 Traceback (most recent call last):
  File "ompl_app.py", line 40, in <module>
    from ompl.util import OutputHandler, useOutputHandler, LogLevel
  File "/home/lc/omplapp/ompl/py-bindings/ompl/util/__init__.py", line 4, in <module>
    from ompl.util._util import *
ImportError: No module named _util

I find someone has the same problem as I have but I can't find the file:
pyplusplus_util.log
at the directory build/Release, am I find the wrong directory or because the update?

TRRT hangs

Original report by Ioan Sucan (Bitbucket: isucan, GitHub: isucan).

---

When running the 2dmap geometric test, TRRT often hangs:

---

Testing TRRT ...

========= Running simple test

Debug: Frontier threshold detected to be 0.212132
Debug: K constant detected to be 0.000000
Info: Starting with 1 states
Info: Created 24 states
Info: Starting with 1 states
Info: Created 134 states
Info: Starting with 134 states

RRT* Numerical Stability

Original report by Ryan Luna (Bitbucket: rluna, GitHub: rluna).

---

Recent floating point precision problems in RRT* are likely due to the addition and subtraction of a temporary cost value that is used to sort nodes inside the inner planning loop:

:::cpp
    for (unsigned int i = 0; i < nbh.size(); ++i)
    {
        double d = si_->distance(nbh[i]->state, motion->state);
        dists[nbh[i]] = d;
        nbh[i]->cost += d;  // here
    }
    std::sort(nbh.begin(), nbh.end(), compareMotion);
    for (unsigned int i = 0; i < nbh.size(); ++i)
        nbh[i]->cost -= dists[nbh[i]];  // and here

We should consider refactoring this code to avoid the unnecessary arithmetic. The tradeoff will likely be a little more overhead in creating a temporary structure to hold "candidate neighbors" and their costs.

clean_bindings does not remove contrib bindings

Original report by Ryan Luna (Bitbucket: rluna, GitHub: rluna).

---

Since the py_bindings have been separated for contributed code, clean_bindings does not properly remove code inside the src/contrib folders. This is the reason for the recent TeamCity build failures.

make test (test 13 failed during installation)

Original report by Anonymous.

---

...
23/24 Test #23: test_control.py ...................   Passed   18.23 sec
      Start 24: test_py_boost_function.py
24/24 Test #24: test_py_boost_function.py .........   Passed    0.07 sec

96% tests passed, 1 tests failed out of 24

Total Test time (real) = 183.51 sec

The following tests FAILED:
	 13 - test_2denvs_geometric (Failed)
Errors while running CTest
make: *** [test] Error 8

TRRT fails often when continuing the computation of a motion plan

Original report by Ioan Sucan (Bitbucket: isucan, GitHub: isucan).

---

If calling solve() for a short period of time, then calling solve() for a long time, makes TRRT fail. It may be the case that this calling pattern for solve() is actually not relevant, and TRRT simply fails often. This needs to be investigated.

mysql generated by benchmark script

Original report by Anonymous.

---

It seems that the benchmark script for generating MySQL produces some code that MySQL does not like. I keep getting error 150 when I generate a table. This seems to be related to a missing index for the foreign keys that tables have.

Feature request: multi core support for benchmarking

Original report by Mark Moll (Bitbucket: mamoll, GitHub: mamoll).

---

It may be useful to have some sort of support for running benchmarking instances in parallel on different cores. E.g., if the user could specify the number of cores through benchmarking class and this class automatically runs multiple instances of planning problem simultaneously accounting for the number of cores and available memory.

RRTstar segfault on incorrect OptimizationObjective

Original report by Anonymous.

---

ompl/geometric/planners/rrt/src/RRTstar.cpp line 103 segfaults trying to print out an error message because in line 102 it set opt to NULL.

Code exerpt:

if (opt && !dynamic_cast<base::PathLengthOptimizationObjective*>(opt))            
{                                                                                 
    opt = NULL;                                                                   
    OMPL_WARN("%s: Optimization objective '%s' specified, but such an objective is not appropriate. Only path length can be optimized.", getName().c_str(), opt->getDescription().c_str());
}

the future of ompl::base::State

Original report by Anonymous.

---

@isucanI've been thinking quite a bit about this recently, and I am leaning to think now that we should actually include the StateSpace pointer (raw) in every state we create.
The advantages of this would be that :
-states can then allocate & destroy themselves (aka, new & delete will do the right thing, no matter what the state is).
-basic functions such as ones in ScopedState<> could be added as passthroughs.
-boost allocators could directly be used to cache states.
-nicer/simpler API for state operations
-no need to distinguish between State and AbstractState in Python? Is this true Mark?

The disadvantages I see are:

• extra memory; but then again, on a current computers that is about 8 MB RAM for 1 million states.
• it would require touching lots of internal code, but I'd like the allocState / freeState functions to stay, so we can insert a state cache for reusing memory, so the changes would mostly be in the alloc/free functions themselves, for each of the implemented state spaces (and control spaces)

Thoughts?

Ioan

OMPL - make update_bindings failed

Original report by Michael Dangler (Bitbucket: mdangler, GitHub: mdangler).

---

Hello

Most likely something simple, I am on MAC OSX. Make ran smooth till the end -

[  1%] Building CXX object src/CMakeFiles/fcl.dir/articulated_model/joint.cpp.o
/Users/michaeldangler/omplapp/build/Release/fcl-prefix/src/fcl/src/articulated_model/joint.cpp:1: error: bad value (native) for -march= switch
/Users/michaeldangler/omplapp/build/Release/fcl-prefix/src/fcl/src/articulated_model/joint.cpp:1: error: bad value (native) for -mtune= switch
make[6]: *** [src/CMakeFiles/fcl.dir/articulated_model/joint.cpp.o] Error 1
make[5]: *** [src/CMakeFiles/fcl.dir/all] Error 2
make[4]: *** [all] Error 2
make[3]: *** [fcl-prefix/src/fcl-stamp/fcl-build] Error 2
make[2]: *** [CMakeFiles/fcl.dir/all] Error 2
make[1]: *** [ompl/py-bindings/CMakeFiles/update_bindings.dir/rule] Error 2
make: *** [update_bindings] Error 2

Thanks for any help.

Cheers, Michael

RRTstar planner assumes symmetric distance/cost functions

Original report by Luis G. Torres (Bitbucket: [Luis Torres](https://bitbucket.org/Luis Torres), ).

---

Currently, OMPL's RRTstar planner is implemented in a way which is invalid for state spaces with asymmetric distance/cost functions, e.g. DubinsStateSpace. To be helpful, I've attached my own OMPL implementation of RRTstar which correctly handles asymmetric distance and cost functions.

The current implementation of RRTstar makes the following assumptions which do not hold in a space like DubinsStateSpace: 1) checkMotion(s1, s2) is the same as checkMotion(s2,s1); 2) distance(s1,s2) is the same as distance(s2,s1); 3) cost(s1,s2) is the same as cost(s2,s1); 4) the nearby neighbors for the connection step are the same as the nearby neighbors for the rewiring step.

Therefore, an RRTstar implementation which works for DubinsStateSpace would do TWO nearest neighborhood searches (one FROM the new motion, and one TO the new motion), and it would perform distinct sets of distance(), cost() and checkMotion() calls for each of the two different neighborhoods. This is of course more computationally intensive, which further motivates having a way of knowing at run-time whether the StateSpace has symmetric distance/cost functions (this way we can save computation if we know the StateSpace's distance/cost functions are symmetric).

Another tangential issue in the current implementation of RRTstar is the assumption of a PathLengthOptimizationObjective. This is unnecessarily strict, since the cost metric only requires certain boundedness, monotonicity, and smoothness properties. In my implementation, I've used the getIncrementalCost() and combineObjectiveCosts() methods of OptimizationObjective in order to generalize the objective optimized by the planner. I've chosen to enforce the use of a BoundedAdditiveOptimizationObjective for semantic reasons, because RRT* assumes that path cost is "accumulated" from one configuration to another (although I think ideally we should enforce the use of a class called something like BoundedAccumulativeOptimizationObjective).

Regarding the

Original report by Fahad Islam (Bitbucket: fislam, GitHub: fislam).

---

the prints are:

#!c++

./ompl_app.py 
Traceback (most recent call last):
  File "./ompl_app.py", line 40, in <module>
    from ompl.util import OutputHandler, useOutputHandler, LogLevel
  File "/home/fahad/Downloads/omplapp-0.12.1-Source/ompl/py-bindings/ompl/util/__init__.py", line 4, in <module>
    from ompl.util._util import *
ImportError: No module named _util

I have issue while starting my GUI. Error log is given above. The code which is creating error is:

#!Python

try:
    from ompl.util import OutputHandler, useOutputHandler, LogLevel
except ImportError:
    sys.path.insert(0, join(dirname(dirname(abspath(__file__))), 'ompl/py-bindings' ) )
    from ompl.util import OutputHandler, useOutputHandler, LogLevel

the last line is the line 40.

The issue is the same as discussed in one of the resolved issues, but I don't get it how it happened, the link with same issue is:
#19/something-wrong-when-typing-python

More is that I am not able to run the following Command

#!Script

make update_bindings

the above command gives the following error:

#!Script
make: *** No rule to make target `update_bindings'.  Stop.

Please tell what I am doing wrong.

Segfaults when doing thousands of RRTconnect calls

Original report by Peter Schüller (Bitbucket: peterschueller, GitHub: peterschueller).

---

I currently use OMPL within MoveIt! to make thousands of RRTconnect motion plans within a high level reasoning framework.

For some of my tests (which run several hours) I sometimes get segfaults, in one case I consistently get segfaults but at various times (from 5 minutes to 8 hours).

I activated core dumps and see the following backtrace in gdb:

#0 0x00002ab473a0ab38 in __GI___libc_malloc (bytes=48) at malloc.c:3660
#1 0x00002ab47330b4cd in operator new(unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#2 0x00002ab47bc1c3b0 in ompl::Grid<ompl::geometric::Discretizationompl::geometric::LBKPIECE1::Motion::CellData*>::neighbors(std::vector<int, std::allocator >&, std::vector<ompl::Grid<ompl::geometric::Discretizationompl::geometric::LBKPIECE1::Motion::CellData*>::Cell*, std::allocator<ompl::Grid<ompl::geometric::Discretizationompl::geometric::LBKPIECE1::Motion::CellData*>::Cell*> >&) const ()
from /opt/ros/groovy/lib/libompl.so.6
#3 0x00002ab47bc1c5cb in ompl::GridN<ompl::geometric::Discretizationompl::geometric::LBKPIECE1::Motion::CellData*>::neighbors(std::vector<int, std::allocator >&, std::vector<ompl::GridN<ompl::geometric::Discretizationompl::geometric::LBKPIECE1::Motion::CellData*>::Cell*, std::allocator<ompl::GridN<ompl::geometric::Discretizationompl::geometric::LBKPIECE1::Motion::CellData*>::Cell*> >&) const ()
from /opt/ros/groovy/lib/libompl.so.6
#4 0x00002ab47bc1ccdf in ompl::GridB<ompl::geometric::Discretizationompl::geometric::LBKPIECE1::Motion::CellData*, ompl::geometric::Discretizationompl::geometric::LBKPIECE1::Motion::OrderCellsByImportance, ompl::geometric::Discretizationompl::geometric::LBKPIECE1::Motion::OrderCellsByImportance>::remove(ompl::GridN<ompl::geometric::Discretizationompl::geometric::LBKPIECE1::Motion::CellData*>::Cell*) ()
from /opt/ros/groovy/lib/libompl.so.6
#5 0x00002ab47bc1713c in ompl::geometric::LBKPIECE1::removeMotion(ompl::geometric::Discretizationompl::geometric::LBKPIECE1::Motion&, ompl::geometric::LBKPIECE1::Motion*) ()
from /opt/ros/groovy/lib/libompl.so.6
#6 0x00002ab47bc16fff in ompl::geometric::LBKPIECE1::removeMotion(ompl::geometric::Discretizationompl::geometric::LBKPIECE1::Motion&, ompl::geometric::LBKPIECE1::Motion*) ()
from /opt/ros/groovy/lib/libompl.so.6
#7 0x00002ab47bc16fff in ompl::geometric::LBKPIECE1::removeMotion(ompl::geometric::Discretizationompl::geometric::LBKPIECE1::Motion&, ompl::geometric::LBKPIECE1::Motion*) ()
from /opt/ros/groovy/lib/libompl.so.6
...
#14526 0x00002ab47bc16fff in ompl::geometric::LBKPIECE1::removeMotion(ompl::geometric::Discretizationompl::geometric::LBKPIECE1::Motion&, ompl::geometric::LBKPIECE1::Motion*) ()
from /opt/ros/groovy/lib/libompl.so.6
#14527 0x00002ab47bc16fff in ompl::geometric::LBKPIECE1::removeMotion(ompl::geometric::Discretizationompl::geometric::LBKPIECE1::Motion&, ompl::geometric::LBKPIECE1::Motion*) ()
from /opt/ros/groovy/lib/libompl.so.6
#14528 0x00002ab47bc18481 in ompl::geometric::LBKPIECE1::isPathValid(ompl::geometric::Discretizationompl::geometric::LBKPIECE1::Motion&, ompl::geometric::LBKPIECE1::Motion*, ompl::base::State*) ()
from /opt/ros/groovy/lib/libompl.so.6
#14529 0x00002ab47bc19210 in ompl::geometric::LBKPIECE1::solve(ompl::base::PlannerTerminationCondition const&) () from /opt/ros/groovy/lib/libompl.so.6
#14530 0x00002ab47bc8f197 in ompl::tools::ParallelPlan::solveMore(ompl::base::Planner*, unsigned long, unsigned long, ompl::base::PlannerTerminationCondition const*) () from /opt/ros/groovy/lib/libompl.so.6
#14531 0x00002ab472dcaba9 in thread_proxy () from /usr//lib/libboost_thread.so.1.46.1
#14532 0x00002ab473776efc in start_thread (arg=0x2ab489257700) at pthread_create.c:304
#14533 0x00002ab473a70f8d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#14534 0x0000000000000000 in ?? ()

This looks like a stack overflow to me, and it is strange that using RRTconnect would use LBKPIECE1 ... or is this intended behavior?

I am sure RRTconnect is used because changing its parameters in the parameter server changes the behavior of the motion planner.

Now this might turn into a MoveIt related issue:

I sometimes (not always!) get the error message

Could not find the planner configuration 'RRTconnect' on the param server

Sometimes multiple times in one run.

Is requesting parameters from the ROS parameter server unreliable? Shouldn't the motion planning context cache request the parameters once and use them?

The thread starting motion planning has the following backtrace:

#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
#1 0x00002ab472dcbe9b in boost::thread::join() () from /usr//lib/libboost_thread.so.1.46.1
#2 0x00002ab47bc8e50c in ompl::tools::ParallelPlan::solve(ompl::base::PlannerTerminationCondition const&, unsigned long, unsigned long, bool) () from /opt/ros/groovy/lib/libompl.so.6
#3 0x00002ab4784b9423 in ompl_interface::ModelBasedPlanningContext::solve(double, unsigned int) () from /home/ps/science/ros/moveit_src/devel/lib/libmoveit_ompl_interface.so
#4 0x00002ab478489405 in ompl_interface::OMPLInterface::solve(boost::shared_ptr<planning_scene::PlanningScene const> const&, moveit_msgs::MotionPlanRequest<std::allocator > const&, planning_interface::MotionPlanResponse&) const () from /home/ps/_science/ros/moveit_src/devel/lib/libmoveit_ompl_interface.so

control::EST reports approximate solutions as exact solutions

Original report by Mark Moll (Bitbucket: mamoll, GitHub: mamoll).

---

In the solve function an extra variable is needed to distinguish approximate solutions from exact solutions (analogous to the way control::KPIECE and control::RRT do it).

Error in generating python bindings and running ompl_app

Original report by Fahad Islam (Bitbucket: fislam, GitHub: fislam).

---

the prints are:

#!c++

./ompl_app.py 
Traceback (most recent call last):
  File "./ompl_app.py", line 40, in <module>
    from ompl.util import OutputHandler, useOutputHandler, LogLevel
  File "/home/fahad/Downloads/omplapp-0.12.1-Source/ompl/py-bindings/ompl/util/__init__.py", line 4, in <module>
    from ompl.util._util import *
ImportError: No module named _util

I have issue while starting my GUI. Error log is given above. The code which is creating error is:

#!Python

try:
    from ompl.util import OutputHandler, useOutputHandler, LogLevel
except ImportError:
    sys.path.insert(0, join(dirname(dirname(abspath(__file__))), 'ompl/py-bindings' ) )
    from ompl.util import OutputHandler, useOutputHandler, LogLevel

the last line is the line 40.

The issue is the same as discussed in one of the resolved issues, but I don't get it how it happened, the link with same issue is:
#19/something-wrong-when-typing-python

More is that I am not able to run the following Command

#!Script

make update_bindings

the above command gives the following error:

#!Script
make: *** No rule to make target `update_bindings'.  Stop.

Please tell what I am doing wrong.

Demo Bug

Original report by Stephen Dunn (Bitbucket: entangledloops, GitHub: entangledloops).

---

Hi guys, you might want to double-check your goal state in the demo below, I believe the start state was accidentally reused (causing the planner to leave (1,0) and return to (1,0) instead of the desired (26,0).

http://ompl.kavrakilab.org/demos_2SE2RigidBodyPlanning_2SE2RigidBodyPlanning_8cpp_source.html

Problem implementing new state space

Original report by neckutrek (Bitbucket: neckutrek, GitHub: neckutrek).

---

I'm having a rigid body motion simulator that I want to use for searching for motion paths. I've implemented the necessary classes from OMPL: ControlSpace, StateSpace, SimpleSetup, StateValidator and StatePropagator. Below is a portion of the code for the StateSpace. The used state space is a CompoundStateSpace with an SE3StateSpace at index 0, and my own (see below) at index 1. I'm thinking that this must be where it's not working properly.

I get this error message when creating an instance of my SimpleSetup class (I have derived my own):
terminate called after throwing an instance of 'ompl::Exception'
what(): The longest valid segment for state space RealVectorSpace8 must be positive

Where can I start to look for the bug? How can I handle this problem? I'm pretty sure that the C++ code is properly written...

Thanks for a great community, and a great library!

#!c++
class LinkQuad_SimulatorStateSpace : public ob::RealVectorStateSpace
{
 public:
  LinkQuad_SimulatorStateSpace();
  virtual ~LinkQuad_SimulatorStateSpace();
  
  virtual ob::State* allocState() const;
  virtual void copyState(ob::State *destination, const ob::State *source) const;
  virtual void freeState(ob::State *state) const;
}

LinkQuad_SimulatorStateSpace::LinkQuad_SimulatorStateSpace()
  : ob::RealVectorStateSpace(1)
{}

LinkQuad_SimulatorStateSpace::~LinkQuad_SimulatorStateSpace()
{}

ob::State* LinkQuad_SimulatorStateSpace::allocState() const
{
  LinkQuad_SimulatorState *value = new LinkQuad_SimulatorState();
  LinkQuad_SimulatorStateSpace::StateType *state = new LinkQuad_SimulatorStateSpace::StateType();
  state->values = (double*)(value);
  return state;
}
  
void LinkQuad_SimulatorStateSpace::copyState
(ob::State *destination, const ob::State *source) const
{
  LinkQuad_SimulatorState value = *(LinkQuad_SimulatorState*)(source->as<LinkQuad_SimulatorStateSpace::StateType>()->values);
  destination->as<LinkQuad_SimulatorStateSpace::StateType>()->values =
    (double*)(new LinkQuad_SimulatorState(value));
  return;
}

void LinkQuad_SimulatorStateSpace::freeState(ob::State *state) const
{
// empty, should delete pointer
}

Hello i have following problem with VS2010 and Win7

Original report by Anonymous.

---

  -- Configuring incomplete, errors occurred!
2>CUSTOMBUILD : CMake error : The following variables are used in this project, but they are set to NOTFOUND.
2>  Please set them or make sure they are set and tested correctly in the CMake files:
2>  MATH
2>      linked by target "ccd" in directory C:/libs/omplapp-0.12.2-Source/build/ccd-prefix/src/ccd
2>      linked by target "ccd_static" in directory C:/libs/omplapp-0.12.2-Source/build/ccd-prefix/src/ccd

regards phil

python ompl_app.py unavailable

Original report by neckutrek (Bitbucket: neckutrek, GitHub: neckutrek).

---

I get these python errors when I try to start the gui using ompl_app.py

#!python

Traceback (most recent call last):
  File "ompl_app.py", line 44, in <module>
    from ompl import app as oa
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/ompl/app/__init__.py", line 15, in <module>
    dll_loader('ompl_app', dirname(abspath(__file__)))
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/ompl/__init__.py", line 27, in dll_loader
    raise ImportError
ImportError

I have done these:

#!gcc

make installpyplusplus
make update_bindings && make

but it's not working anyway.

Problem with downloading fcl when building omplapp

Original report by berenson (Bitbucket: berenson, GitHub: berenson).

---

Hello,

I'm trying to install omplapp's python bindings for the omplapp tarball I get from here: http://ompl.kavrakilab.org/download.html. When running "make update_bindings" after a while I get this error:

[ 75%] Performing download step (download, verify and extract) for 'fcl'
-- downloading...
src='http://downloads.sourceforge.net/project/ompl/dependencies/fcl-0.2.5.zip'
dst='/home/berenson/omplapp/src/external/fcl-0.2.5.zip'
timeout='none'
CMake Error at fcl-stamp/download-fcl.cmake:6 (file):
file DOWNLOAD MD5 mismatch

for file: [/home/berenson/omplapp/src/external/fcl-0.2.5.zip]
  expected MD5 sum: [d0164f6454cda76d50ff53052be2fd45]
    actual MD5 sum: [d41d8cd98f00b204e9800998ecf8427e]

When I try to open the zipfile manually, I get this error:

Archive: /home/berenson/omplapp/src/external/fcl-0.2.5.zip
[/home/berenson/omplapp/src/external/fcl-0.2.5.zip]
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
zipinfo: cannot find zipfile directory in one of /home/berenson/omplapp/src/external/fcl-0.2.5.zip or
/home/berenson/omplapp/src/external/fcl-0.2.5.zip.zip, and cannot find /home/berenson/omplapp/src/external/fcl-0.2.5.zip.ZIP, period.

It seems the file is somehow corrupted.

Thanks!

Dmitry

Wrong solution by DubinsStateSpace

Original report by Anonymous.

---

Dear developers,

Thank you for developing OMPL. I found a wrong result when testing the DubinsStateSpace.cpp file. For example, if you want to get a Dubins path from configuration (0 0 PI/2) to configuration (1 0 -PI/2), with turning radius 1, the path type should be LRL. But it is not using OMPL.

Maybe you can modify such lines:\
double p = acos(tmp);\
if ( p<boost::math::constants::pi() )\
{\
p = twopi - p; \
}\
in both dubinsRLR and dubinsLRL functions of DubinsStateSpace.cpp.
Then the issue may be solved.

Sincerely,

Steve

PlannerThreadedTerminationCondition locking problem causes RRT* planner to freeze while improving solution

Original report by Anonymous.

---

There is some kind of a problem in the PlannerThreadedTerminationCondition that causes a deadlock. This problem appears sometimes when improving an existing solution using the RRT* planner. The planner was given 20 seconds of time and invoked through SimpleSetup with:

ob::PlannerStatus solution=setup->solve(solve_t_limit);

RRT* efficiency

Original report by Ioan Sucan (Bitbucket: isucan, GitHub: isucan).

---

Lines 185 and 192 in RRTstart.cpp compute the same distances, but in a different order. It seems this can be done a bit more efficiently, by storing the distances in a map and doing a lookup by state pointer when initializing dists[i]. This same issue holds true for BallTreeRRTstar as well (lines 223, 233, 241)

Pi Range Disagreement

Original report by Stephen Dunn (Bitbucket: entangledloops, GitHub: entangledloops).

---

The docs here use the eulerRPY function to generate a random value in the range [-pi, pi). However, an SO2State enforces bounds in the range of (-pi, pi]. You might want to consider adjusting one or the other to agree.

OMPL.app 0.12 compile issue

Original report by Anonymous.

---

Hi,

It seems there is some problems with OMPL.app and FCL, that create errors in the compilation:

In file included from /home/tienthanh/Dev/omplapp-0.12.0/src/omplapp/geometry/detail/FCLStateValidityChecker.h:23:0,
from /home/tienthanh/Dev/omplapp-0.12.0/src/omplapp/geometry/RigidBodyGeometry.cpp:17:
/home/tienthanh/Dev/omplapp-0.12.0/src/omplapp/geometry/detail/FCLMethodWrapper.h: In member function ‘virtual bool ompl::app::FCLMethodWrapper::isValid(const ompl::base::State*, const ompl::base::State*, double&) const’:
/home/tienthanh/Dev/omplapp-0.12.0/src/omplapp/geometry/detail/FCLMethodWrapper.h:147:43: error: missing template arguments before ‘motion1’
/home/tienthanh/Dev/omplapp-0.12.0/src/omplapp/geometry/detail/FCLMethodWrapper.h:147:43: error: expected ‘;’ before ‘motion1’
/home/tienthanh/Dev/omplapp-0.12.0/src/omplapp/geometry/detail/FCLMethodWrapper.h:149:43: error: missing template arguments before ‘motion2’
/home/tienthanh/Dev/omplapp-0.12.0/src/omplapp/geometry/detail/FCLMethodWrapper.h:149:43: error: expected ‘;’ before ‘motion2’
/home/tienthanh/Dev/omplapp-0.12.0/src/omplapp/geometry/detail/FCLMethodWrapper.h:152:73: error: ‘MeshConservativeAdvancementTraversalNodeOBBRSS’ is not a member of ‘fcl’
/home/tienthanh/Dev/omplapp-0.12.0/src/omplapp/geometry/detail/FCLMethodWrapper.h:152:73: error: ‘MeshConservativeAdvancementTraversalNodeOBBRSS’ is not a member of ‘fcl’
In file included from /home/tienthanh/Dev/omplapp-0.12.0/src/omplapp/geometry/detail/FCLStateValidityChecker.h:23:0,
from /home/tienthanh/Dev/omplapp-0.12.0/src/omplapp/geometry/RigidBodyGeometry.cpp:17:
/home/tienthanh/Dev/omplapp-0.12.0/src/omplapp/geometry/detail/FCLMethodWrapper.h:153:48: error: ‘motion1’ was not declared in this scope
/home/tienthanh/Dev/omplapp-0.12.0/src/omplapp/geometry/detail/FCLMethodWrapper.h:153:73: error: ‘motion2’ was not declared in this scope
/home/tienthanh/Dev/omplapp-0.12.0/src/omplapp/geometry/detail/FCLMethodWrapper.h:170:43: error: missing template arguments before ‘motion_i’
/home/tienthanh/Dev/omplapp-0.12.0/src/omplapp/geometry/detail/FCLMethodWrapper.h:170:43: error: expected ‘;’ before ‘motion_i’
/home/tienthanh/Dev/omplapp-0.12.0/src/omplapp/geometry/detail/FCLMethodWrapper.h:181:47: error: missing template arguments before ‘motion_j’
/home/tienthanh/Dev/omplapp-0.12.0/src/omplapp/geometry/detail/FCLMethodWrapper.h:181:47: error: expected ‘;’ before ‘motion_j’
/home/tienthanh/Dev/omplapp-0.12.0/src/omplapp/geometry/detail/FCLMethodWrapper.h:184:77: error: ‘MeshConservativeAdvancementTraversalNodeOBBRSS’ is not a member of ‘fcl’
/home/tienthanh/Dev/omplapp-0.12.0/src/omplapp/geometry/detail/FCLMethodWrapper.h:184:77: error: ‘MeshConservativeAdvancementTraversalNodeOBBRSS’ is not a member of ‘fcl’
/home/tienthanh/Dev/omplapp-0.12.0/src/omplapp/geometry/detail/FCLMethodWrapper.h:185:52: error: ‘motion_i’ was not declared in this scope
/home/tienthanh/Dev/omplapp-0.12.0/src/omplapp/geometry/detail/FCLMethodWrapper.h:185:80: error: ‘motion_j’ was not declared in this scope
make[2]: *** [src/omplapp/CMakeFiles/ompl_app.dir/geometry/RigidBodyGeometry.cpp.o] Error 1
make[1]: *** [src/omplapp/CMakeFiles/ompl_app.dir/all] Error 2
make: *** [all] Error 2

System: FCL Ros Fuerte, OMPL.app0.12.0, Ubuntu 12.04 32bit

benchmark cfg file parameter parsing errors

Original report by Mark Moll (Bitbucket: mamoll, GitHub: mamoll).

---

The .cfg files for the ompl_benchmark program are not parsed correctly. These settings in the [problem] section are accepted, but completed ignored:

projection.cellsize.0=2
projection.cellsize.1=2
projection.cellsize.2=2

On the other hand, this setting is applied each time for each planner to the value used for the previous planner:

projection.cellsize_factor=.5

So the effective cellsize_factor is .5 for the first planner, .25 for the second planner, ... , .5^n for the n-th planner.

Segfaults with RRTstar

Original report by Peter Schüller (Bitbucket: peterschueller, GitHub: peterschueller).

---

I am doing many RRTstar motion plans and sometimes I get segfaults within OMPL.

I updated to the latest OMPL, built it, and rebuilt moveit and I can verify that moveit links to my build of libompl.so

(This time the problem is not like in #39, I am sure that I really use RRTstar all the time.)

The segfault seems to be timing-related as I cannot reproduce it with valgrind or gdb, I can only analyze post-mortem core-dumps, they look as follows:

(gdb) info threads
  Id   Target Id         Frame 
  9    Thread 0x2b3425237700 (LWP 20707) 0x00002b341fe64afe in fcl::obbDisjoint(fcl::Matrix3fX<fcl::details::Matrix3Data<double> > const&, fcl::Vec3fX<fcl::details::Vec3Data<double> > const&, fcl::Vec3fX<fcl::details::Vec3Data<double> > const&, fcl::Vec3fX<fcl::details::Vec3Data<double> > const&) () from /opt/ros/groovy/lib/libfcl.so
  8    Thread 0x2b3425033700 (LWP 20022) pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
  7    Thread 0x2b34245e4700 (LWP 19971) pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
  6    Thread 0x2b34241e2700 (LWP 19969) 0x00002b341497be63 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
  5    Thread 0x2b341847ce60 (LWP 19958) sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:86
  4    Thread 0x2b34247e5700 (LWP 19991) pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
  3    Thread 0x2b34243e3700 (LWP 19970) 0x00002b3414981003 in select () at ../sysdeps/unix/syscall-template.S:82
  2    Thread 0x2b3425639700 (LWP 20709) __memcmp_sse4_1 () at ../sysdeps/x86_64/multiarch/memcmp-sse4.S:45
* 1    Thread 0x2b3425438700 (LWP 20708) 0x00002b341e1de0cd in ompl::geometric::RRTstar::updateChildCosts(ompl::geometric::RRTstar::Motion*, double) () from /usr/local/lib/libompl.so.6

Thread 1 (here the segfault happens, it looks like an infinite recursion):

(gdb) bt
#0  0x00002b341e1de0cd in ompl::geometric::RRTstar::updateChildCosts(ompl::geometric::RRTstar::Motion*, double) () from /usr/local/lib/libompl.so.6
#1  0x00002b341e1de0d7 in ompl::geometric::RRTstar::updateChildCosts(ompl::geometric::RRTstar::Motion*, double) () from /usr/local/lib/libompl.so.6
#2  0x00002b341e1de0d7 in ompl::geometric::RRTstar::updateChildCosts(ompl::geometric::RRTstar::Motion*, double) () from /usr/local/lib/libompl.so.6
#3  0x00002b341e1de0d7 in ompl::geometric::RRTstar::updateChildCosts(ompl::geometric::RRTstar::Motion*, double) () from /usr/local/lib/libompl.so.6
#4  0x00002b341e1de0d7 in ompl::geometric::RRTstar::updateChildCosts(ompl::geometric::RRTstar::Motion*, double) () from /usr/local/lib/libompl.so.6
#5  0x00002b341e1de0d7 in ompl::geometric::RRTstar::updateChildCosts(ompl::geometric::RRTstar::Motion*, double) () from /usr/local/lib/libompl.so.6
#6  0x00002b341e1de0d7 in ompl::geometric::RRTstar::updateChildCosts(ompl::geometric::RRTstar::Motion*, double) () from /usr/local/lib/libompl.so.6
#7  0x00002b341e1de0d7 in ompl::geometric::RRTstar::updateChildCosts(ompl::geometric::RRTstar::Motion*, double) () from /usr/local/lib/libompl.so.6
#8  0x00002b341e1de0d7 in ompl::geometric::RRTstar::updateChildCosts(ompl::geometric::RRTstar::Motion*, double) () from /usr/local/lib/libompl.so.6
#9  0x00002b341e1de0d7 in ompl::geometric::RRTstar::updateChildCosts(ompl::geometric::RRTstar::Motion*, double) () from /usr/local/lib/libompl.so.6
#10 0x00002b341e1de0d7 in ompl::geometric::RRTstar::updateChildCosts(ompl::geometric::RRTstar::Motion*, double) () from /usr/local/lib/libompl.so.6
...
...
#43577 0x00002b341e1de0d7 in ompl::geometric::RRTstar::updateChildCosts(ompl::geometric::RRTstar::Motion*, double) () from /usr/local/lib/libompl.so.6
#43578 0x00002b341e1de0d7 in ompl::geometric::RRTstar::updateChildCosts(ompl::geometric::RRTstar::Motion*, double) () from /usr/local/lib/libompl.so.6
#43579 0x00002b341e1de0d7 in ompl::geometric::RRTstar::updateChildCosts(ompl::geometric::RRTstar::Motion*, double) () from /usr/local/lib/libompl.so.6
#43580 0x00002b341e1e0b55 in ompl::geometric::RRTstar::solve(ompl::base::PlannerTerminationCondition const&) () from /usr/local/lib/libompl.so.6
#43581 0x00002b341e27a847 in ompl::tools::ParallelPlan::solveMore(ompl::base::Planner*, unsigned long, unsigned long, ompl::base::PlannerTerminationCondition const*) () from /usr/local/lib/libompl.so.6
#43582 0x00002b3413ce1ba9 in thread_proxy () from /usr//lib/libboost_thread.so.1.46.1
#43583 0x00002b341468defc in start_thread (arg=0x2b3425438700) at pthread_create.c:304
#43584 0x00002b3414987f8d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#43585 0x0000000000000000 in ?? ()

Thread 9:

(gdb) bt
#0  0x00002b341fe64afe in fcl::obbDisjoint(fcl::Matrix3fX<fcl::details::Matrix3Data<double> > const&, fcl::Vec3fX<fcl::details::Vec3Data<double> > const&, fcl::Vec3fX<fcl::details::Vec3Data<double> > const&, fcl::Vec3fX<fcl::details::Vec3Data<double> > const&) () from /opt/ros/groovy/lib/libfcl.so
#1  0x00002b341fe65458 in fcl::overlap(fcl::Matrix3fX<fcl::details::Matrix3Data<double> > const&, fcl::Vec3fX<fcl::details::Vec3Data<double> > const&, fcl::OBB const&, fcl::OBB const&) ()
   from /opt/ros/groovy/lib/libfcl.so
#2  0x00002b341ffdcc89 in fcl::MeshCollisionTraversalNodeOBBRSS::BVTesting(int, int) const () from /opt/ros/groovy/lib/libfcl.so
#3  0x00002b341ffdb14d in fcl::collisionRecurse(fcl::CollisionTraversalNodeBase*, int, int, std::list<fcl::BVHFrontNode, std::allocator<fcl::BVHFrontNode> >*) () from /opt/ros/groovy/lib/libfcl.so
#4  0x00002b341fef193b in unsigned long fcl::details::orientedMeshCollide<fcl::MeshCollisionTraversalNodeOBBRSS, fcl::OBBRSS>(fcl::CollisionGeometry const*, fcl::Transform3f const&, fcl::CollisionGeometry const*, fcl::Transform3f const&, fcl::CollisionRequest const&, fcl::CollisionResult&) () from /opt/ros/groovy/lib/libfcl.so
#5  0x00002b341fe6e6fe in unsigned long fcl::collide<fcl::GJKSolver_libccd>(fcl::CollisionGeometry const*, fcl::Transform3f const&, fcl::CollisionGeometry const*, fcl::Transform3f const&, fcl::GJKSolver_libccd const*, fcl::CollisionRequest const&, fcl::CollisionResult&) () from /opt/ros/groovy/lib/libfcl.so
#6  0x00002b341fe6e8a4 in unsigned long fcl::collide<fcl::GJKSolver_libccd>(fcl::CollisionObject const*, fcl::CollisionObject const*, fcl::GJKSolver_libccd const*, fcl::CollisionRequest const&, fcl::CollisionResult&) () from /opt/ros/groovy/lib/libfcl.so
#7  0x00002b341fe6e525 in fcl::collide(fcl::CollisionObject const*, fcl::CollisionObject const*, fcl::CollisionRequest const&, fcl::CollisionResult&) () from /opt/ros/groovy/lib/libfcl.so
#8  0x00002b341cf05633 in collision_detection::collisionCallback(fcl::CollisionObject*, fcl::CollisionObject*, void*) () from /home/ps/_science/ros/moveit_src/devel/lib/libmoveit_collision_detection_fcl.so
#9  0x00002b342007e1ff in fcl::details::dynamic_AABB_tree::collisionRecurse(fcl::NodeBase<fcl::AABB>*, fcl::CollisionObject*, void*, bool (*)(fcl::CollisionObject*, fcl::CollisionObject*, void*)) ()
   from /opt/ros/groovy/lib/libfcl.so
#10 0x00002b342007e1ff in fcl::details::dynamic_AABB_tree::collisionRecurse(fcl::NodeBase<fcl::AABB>*, fcl::CollisionObject*, void*, bool (*)(fcl::CollisionObject*, fcl::CollisionObject*, void*)) ()
   from /opt/ros/groovy/lib/libfcl.so
#11 0x00002b342007e1ff in fcl::details::dynamic_AABB_tree::collisionRecurse(fcl::NodeBase<fcl::AABB>*, fcl::CollisionObject*, void*, bool (*)(fcl::CollisionObject*, fcl::CollisionObject*, void*)) ()
   from /opt/ros/groovy/lib/libfcl.so
#12 0x00002b3420081869 in fcl::DynamicAABBTreeCollisionManager::collide(fcl::CollisionObject*, void*, bool (*)(fcl::CollisionObject*, fcl::CollisionObject*, void*)) const () from /opt/ros/groovy/lib/libfcl.so
#13 0x00002b341cf15390 in collision_detection::CollisionWorldFCL::checkRobotCollisionHelper(collision_detection::CollisionRequest const&, collision_detection::CollisionResult&, collision_detection::CollisionRobot const&, robot_state::RobotState const&, collision_detection::AllowedCollisionMatrix const*) const () from /home/ps/_science/ros/moveit_src/devel/lib/libmoveit_collision_detection_fcl.so
#14 0x00002b34198f363b in planning_scene::PlanningScene::checkCollision(collision_detection::CollisionRequest const&, collision_detection::CollisionResult&, robot_state::RobotState const&) const ()
   from /home/ps/_science/ros/moveit_src/devel/lib/libmoveit_planning_scene.so
#15 0x00002b341a67362f in ompl_interface::StateValidityChecker::isValidWithCache(ompl::base::State const*, bool) const () from /home/ps/_science/ros/moveit_src/devel/lib/libmoveit_ompl_interface.so
#16 0x00002b341a677124 in ompl_interface::ConstrainedGoalSampler::sampleUsingConstraintSampler(ompl::base::GoalLazySamples const*, ompl::base::State*) ()
   from /home/ps/_science/ros/moveit_src/devel/lib/libmoveit_ompl_interface.so
#17 0x00002b341e0d6e3b in ompl::base::GoalLazySamples::goalSamplingThread() () from /usr/local/lib/libompl.so.6
#18 0x00002b3413ce1ba9 in thread_proxy () from /usr//lib/libboost_thread.so.1.46.1
#19 0x00002b341468defc in start_thread (arg=0x2b3425237700) at pthread_create.c:304
#20 0x00002b3414987f8d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#21 0x0000000000000000 in ?? ()

Thread 8:

(gdb) bt
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
#1  0x00002b3413ce2e9b in boost::thread::join() () from /usr//lib/libboost_thread.so.1.46.1
#2  0x00002b341e279bbc in ompl::tools::ParallelPlan::solve(ompl::base::PlannerTerminationCondition const&, unsigned long, unsigned long, bool) () from /usr/local/lib/libompl.so.6
#3  0x00002b341a65c433 in ompl_interface::ModelBasedPlanningContext::solve(double, unsigned int) () from /home/ps/_science/ros/moveit_src/devel/lib/libmoveit_ompl_interface.so
#4  0x00002b341a62c415 in ompl_interface::OMPLInterface::solve(boost::shared_ptr<planning_scene::PlanningScene const> const&, moveit_msgs::MotionPlanRequest_<std::allocator<void> > const&, planning_interface::MotionPlanResponse&) const () from /home/ps/_science/ros/moveit_src/devel/lib/libmoveit_ompl_interface.so
#5  0x00002b3418bbff88 in pm::PlanMotion::Impl::pathExists(int, int, int, int, double*, pm::PlanMotion::PlannerConfiguration const&, std::vector<pm::PlanMotion::Obstacle, std::allocator<pm::PlanMotion::Obstacle> > const&) const () from /home/ps/_science/planning_levels_of_integration/experiments/ros_catkin_ws/devel/lib/libhousekeep-util.so
#6  0x00002b3418bbcf30 in pm::PlanMotion::pathExists(int, int, int, int, double*, pm::PlanMotion::PlannerConfiguration const&, std::vector<pm::PlanMotion::Obstacle, std::allocator<pm::PlanMotion::Obstacle> > const&) const () from /home/ps/_science/planning_levels_of_integration/experiments/ros_catkin_ws/devel/lib/libhousekeep-util.so
#7  0x00002b341882861b in dlvhex::housekeeping::CumulativePathExistsObstaclesAtom::retrieve(dlvhex::PluginAtom::Query const&, dlvhex::PluginAtom::Answer&, boost::shared_ptr<dlvhex::NogoodContainer>) ()
   from ./lib/libdlvhexplugin-housekeeping.so
#8  0x00002b341323561c in dlvhex::BaseModelGenerator::evaluateExternalAtomQuery(dlvhex::PluginAtom::Query&, dlvhex::BaseModelGenerator::ExternalAnswerTupleCallback&, boost::shared_ptr<dlvhex::NogoodContainer>) const () from /home/ps/_science/hex/core/build_benchmark_boost146/install/lib/libdlvhex2-base.so.7
#9  0x00002b34132364a3 in dlvhex::BaseModelGenerator::evaluateExternalAtom(dlvhex::ProgramCtx&, dlvhex::ExternalAtom const&, boost::shared_ptr<dlvhex::Interpretation const>, dlvhex::BaseModelGenerator::ExternalAnswerTupleCallback&, boost::shared_ptr<dlvhex::NogoodContainer>) const () from /home/ps/_science/hex/core/build_benchmark_boost146/install/lib/libdlvhex2-base.so.7
#10 0x00002b34132e55ff in dlvhex::GenuineGuessAndCheckModelGenerator::verifyExternalAtom(int, boost::shared_ptr<dlvhex::Interpretation const>, boost::shared_ptr<dlvhex::Interpretation const>, boost::shared_ptr<dlvhex::Interpretation const>) () from /home/ps/_science/hex/core/build_benchmark_boost146/install/lib/libdlvhex2-base.so.7
#11 0x00002b34132e653a in dlvhex::GenuineGuessAndCheckModelGenerator::verifyExternalAtoms(boost::shared_ptr<dlvhex::Interpretation const>, boost::shared_ptr<dlvhex::Interpretation const>, boost::shared_ptr<dlvhex::Interpretation const>) () from /home/ps/_science/hex/core/build_benchmark_boost146/install/lib/libdlvhex2-base.so.7
#12 0x00002b34132e6a12 in dlvhex::GenuineGuessAndCheckModelGenerator::propagate(boost::shared_ptr<dlvhex::Interpretation const>, boost::shared_ptr<dlvhex::Interpretation const>, boost::shared_ptr<dlvhex::Interpretation const>) () from /home/ps/_science/hex/core/build_benchmark_boost146/install/lib/libdlvhex2-base.so.7
#13 0x00002b3413259740 in dlvhex::ClaspSolver::ExternalPropagator::prop(Clasp::Solver&) () from /home/ps/_science/hex/core/build_benchmark_boost146/install/lib/libdlvhex2-base.so.7
#14 0x00002b34132625f5 in dlvhex::ClaspSolver::ExternalPropagator::propagate(Clasp::Solver&) () from /home/ps/_science/hex/core/build_benchmark_boost146/install/lib/libdlvhex2-base.so.7
#15 0x00002b34134842ae in Clasp::PostPropagator::propagateFixpoint(Clasp::Solver&) () from /home/ps/_science/hex/core/build_benchmark_boost146/install/lib/libdlvhex2-base.so.7
#16 0x00002b3413484173 in Clasp::Solver::PPList::propagate(Clasp::Solver&, Clasp::PostPropagator*) const () from /home/ps/_science/hex/core/build_benchmark_boost146/install/lib/libdlvhex2-base.so.7
#17 0x00002b3413486cab in Clasp::Solver::propagate() () from /home/ps/_science/hex/core/build_benchmark_boost146/install/lib/libdlvhex2-base.so.7
#18 0x00002b341348bb52 in Clasp::Solver::search(Clasp::SearchLimits&, double) () from /home/ps/_science/hex/core/build_benchmark_boost146/install/lib/libdlvhex2-base.so.7
#19 0x00002b3413481c73 in Clasp::SolveAlgorithm::solvePath(Clasp::Solver&, Clasp::SolveParams const&, Clasp::SolveLimits&) ()
   from /home/ps/_science/hex/core/build_benchmark_boost146/install/lib/libdlvhex2-base.so.7
#20 0x00002b3413482a49 in Clasp::SimpleSolve::doSolve(Clasp::Solver&, Clasp::SolveParams const&) () from /home/ps/_science/hex/core/build_benchmark_boost146/install/lib/libdlvhex2-base.so.7
#21 0x00002b3413480f60 in Clasp::SolveAlgorithm::solve(Clasp::SharedContext&, Clasp::SolveParams const&, bk_lib::pod_vector<Clasp::Literal, std::allocator<Clasp::Literal> > const&) ()
   from /home/ps/_science/hex/core/build_benchmark_boost146/install/lib/libdlvhex2-base.so.7
#22 0x00002b3413480d8b in Clasp::solve(Clasp::SharedContext&, Clasp::SolveParams const&, bk_lib::pod_vector<Clasp::Literal, std::allocator<Clasp::Literal> > const&, Clasp::SolveLimits const&) ()
   from /home/ps/_science/hex/core/build_benchmark_boost146/install/lib/libdlvhex2-base.so.7
#23 0x00002b3413258cf5 in dlvhex::ClaspSolver::runClasp() () from /home/ps/_science/hex/core/build_benchmark_boost146/install/lib/libdlvhex2-base.so.7
#24 0x00002b3413ce1ba9 in thread_proxy () from /usr//lib/libboost_thread.so.1.46.1
#25 0x00002b341468defc in start_thread (arg=0x2b3425033700) at pthread_create.c:304
#26 0x00002b3414987f8d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#27 0x0000000000000000 in ?? ()

Thread 2:

(gdb) bt
#0  __memcmp_sse4_1 () at ../sysdeps/x86_64/multiarch/memcmp-sse4.S:45
#1  0x00002b341420ac73 in std::string::compare(std::string const&) const () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#2  0x00002b341340e989 in bool std::operator< <char, std::char_traits<char>, std::allocator<char> >(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () from /home/ps/_science/hex/core/build_benchmark_boost146/install/lib/libdlvhex2-base.so.7
#3  0x00002b3419b4df42 in collision_detection::AllowedCollisionMatrix::getEntry(std::string const&, std::string const&, collision_detection::AllowedCollision::Type&) const ()
   from /home/ps/_science/ros/moveit_src/devel/lib/libmoveit_collision_detection.so
#4  0x00002b3419b4e0b1 in collision_detection::AllowedCollisionMatrix::getAllowedCollision(std::string const&, std::string const&, collision_detection::AllowedCollision::Type&) const ()
   from /home/ps/_science/ros/moveit_src/devel/lib/libmoveit_collision_detection.so
#5  0x00002b341cf042fc in collision_detection::collisionCallback(fcl::CollisionObject*, fcl::CollisionObject*, void*) () from /home/ps/_science/ros/moveit_src/devel/lib/libmoveit_collision_detection_fcl.so
#6  0x00002b342007e1ff in fcl::details::dynamic_AABB_tree::collisionRecurse(fcl::NodeBase<fcl::AABB>*, fcl::CollisionObject*, void*, bool (*)(fcl::CollisionObject*, fcl::CollisionObject*, void*)) ()
   from /opt/ros/groovy/lib/libfcl.so
#7  0x00002b342007e1ff in fcl::details::dynamic_AABB_tree::collisionRecurse(fcl::NodeBase<fcl::AABB>*, fcl::CollisionObject*, void*, bool (*)(fcl::CollisionObject*, fcl::CollisionObject*, void*)) ()
   from /opt/ros/groovy/lib/libfcl.so
#8  0x00002b3420081869 in fcl::DynamicAABBTreeCollisionManager::collide(fcl::CollisionObject*, void*, bool (*)(fcl::CollisionObject*, fcl::CollisionObject*, void*)) const () from /opt/ros/groovy/lib/libfcl.so
#9  0x00002b341cf15390 in collision_detection::CollisionWorldFCL::checkRobotCollisionHelper(collision_detection::CollisionRequest const&, collision_detection::CollisionResult&, collision_detection::CollisionRobot const&, robot_state::RobotState const&, collision_detection::AllowedCollisionMatrix const*) const () from /home/ps/_science/ros/moveit_src/devel/lib/libmoveit_collision_detection_fcl.so
#10 0x00002b34198f363b in planning_scene::PlanningScene::checkCollision(collision_detection::CollisionRequest const&, collision_detection::CollisionResult&, robot_state::RobotState const&) const ()
   from /home/ps/_science/ros/moveit_src/devel/lib/libmoveit_planning_scene.so
#11 0x00002b341a67362f in ompl_interface::StateValidityChecker::isValidWithCache(ompl::base::State const*, bool) const () from /home/ps/_science/ros/moveit_src/devel/lib/libmoveit_ompl_interface.so
#12 0x00002b341e132f27 in ompl::base::DiscreteMotionValidator::checkMotion(ompl::base::State const*, ompl::base::State const*) const () from /usr/local/lib/libompl.so.6
#13 0x00002b341e1e0964 in ompl::geometric::RRTstar::solve(ompl::base::PlannerTerminationCondition const&) () from /usr/local/lib/libompl.so.6
#14 0x00002b341e27a847 in ompl::tools::ParallelPlan::solveMore(ompl::base::Planner*, unsigned long, unsigned long, ompl::base::PlannerTerminationCondition const*) () from /usr/local/lib/libompl.so.6
#15 0x00002b3413ce1ba9 in thread_proxy () from /usr//lib/libboost_thread.so.1.46.1
#16 0x00002b341468defc in start_thread (arg=0x2b3425639700) at pthread_create.c:304
#17 0x00002b3414987f8d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#18 0x0000000000000000 in ?? ()

(The other threads are roscpp, ros-xmlrpc threads and a logic programming solver.)

Do you have any idea how I could reproduce the problem more deterministically? Can I set a random seed and a fixed number of computations after which RRTstar has to give up, instead of a timeout?

Upgrade to 0.13 fails w/Error: NONE

Original report by Stephen Dunn (Bitbucket: entangledloops, GitHub: entangledloops).

---

Log attached. Did:

sudo port sync ;
sudo port install ompl +app

also tried:
sudo port selfupdate;
sudo port update outgraded #ompl was already installed (0.12)

also did a complete ompl uninstall, reinstall. using boost 1.54 & pygccxml, which I'm aware there was a conflict between previously that you resolved. for the sake of it, i uninstalled pygccxml and tried letting the ompl installer re-install it during "install ompl +app", which it did, but no luck (always fails during configuration).

Thanks! Any help appreciated. Otherwise, for now back to Ubuntu....

OSX Homebrew - Python Bindings not working.

Original report by Andrew Dobson (Bitbucket: chuples, ).

---

Hello all,

I have been trying a slightly experimental build of OMPLapp using OSX homebrew, and have run into a bit of a snag. Pyplusplus_util seems to be failing, and it produces the log file, pyplusplus_util.log.

So, it's a little bit ugly, but it seemed at first to be an issue with Clang. Investigating that, I found that I have Clang 3.1, which seems that there used to be issues with, but were fixed with OMPL 0.10.1. I figure it has to be something very specific with my system configuration:

OSX Lion 10.7.4

Through Homebrew, I installed the dependencies:
*Cmake
*Assimp
*ODE
*Doxygen
*PyQt

Through pip, I installed the dependencies:
*pyplusplus
*pyopengl

As per the instructions on the install page, I ran the line:

make installpyplusplus && cmake . # download & install Py++

then tried running

make update_bindings

which is what produces that log file. I had a short correspondence with Mark Moll on the issue, and he recommended running:

make installpyplusplus && make clean_bindings && make update_bindings

This didn't help unfortunately. He also asked me to install the command line tools through XCode, which I have, so that was not the issue.

Possible issues which do not necessarily seem related, but very well could be follow.
*The iMac I'm working on came pre-installed with boost (or perhaps it is installed automatically with homebrew, not sure), therefore I was unable to set any build flags for it.
*I don't have a full installation of PQP, as it's not on Homebrew.

I did double check to make sure that python27 is what is installed. So I don't think it's a python version mismatch. Now, as I am not using ports at all, I am trying a source install, which seems to be up-to-date at v.0.11. The other parts of OMPL all seem to be building and running (I can run experiments without GUI and they seem to work).

That's all I can think to put in for now. If you have any more questions, feel free to ask, and thank you for your time.

Problem with computing State clearance direction

Original report by Anonymous.

---

Hi, I want to calculate the direction of the "clearance" for each state, which is the direction to the closest collision in the environment. Is there a way I can do it?

Missing CMakeModule in Tarball omplapp-0.12.1-Source.tar.gz

Original report by berenson (Bitbucket: berenson, GitHub: berenson).

---

Hi,

I tried to install ompl.app from the tarball here:

http://ompl.kavrakilab.org/download.html

The file is: omplapp-0.12.1-Source.tar.gz

I'm using Ubuntu Linux 11.10.

It seems that the "WriteBasicConfigVersionFile" CMake module is missing.

Here is the error I get when I run CMake in the build/Release directory:

#!

-- The CXX compiler identification is GNU
-- The C compiler identification is GNU
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Boost version: 1.46.1
-- Found the following Boost libraries:
--   date_time
--   thread
--   program_options
--   serialization
--   filesystem
--   system
--   unit_test_framework
-- Boost version: 1.46.1
-- Found the following Boost libraries:
--   python
-- Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so
-- Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so - found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Found X11: /usr/lib/x86_64-linux-gnu/libX11.so
-- Found OpenGL: /usr/lib/x86_64-linux-gnu/libGL.so 
-- Found Python: /usr/lib/python2.7/config/libpython2.7.so 
-- Found PY_OpenGL: /usr/lib/pymodules/python2.7/OpenGL 
-- checking for module 'ccd=1.4'
--   package 'ccd=1.4' not found
-- checking for module 'fcl>=0.2.4'
--   package 'fcl>=0.2.4' not found
-- CCD library not found.  Will download and compile.
-- FCL library not found.  Will download and compile.
-- checking for module 'assimp'
--   found assimp, version 2.0
-- Found assimp: assimp 
CMake Error at CMakeLists.txt:184 (include):
  include could not find load file:

    WriteBasicConfigVersionFile


CMake Error at CMakeLists.txt:185 (write_basic_config_version_file):
  Unknown CMake command "write_basic_config_version_file".


-- Configuring incomplete, errors occurred!

Thanks!

Dmitry

ompl.app no longer in repository?

Original report by Peter Schüller (Bitbucket: peterschueller, GitHub: peterschueller).

---

Due to issue #10 i started building ompl from the HG repository.

Unfortunately I cannot find the "app" part of ompl anymore. Is this in a separate repository or has the structure of the project changes so that I cannot find it anymore?

RRTstar crashes when run on DubinsStateSpace

Original report by Luis G. Torres (Bitbucket: [Luis Torres](https://bitbucket.org/Luis Torres), ).

---

I directly took the GeometricCarPlanning.cpp demo, and made the following changes:

• changed the planner to RRTstar
• changed the minimum turning radius on the car to 2.0 (this bug has also occurred with rho=1.5)

I then ran the planner on the "easy" scenario with the Dubins state space. Quite frequently (although not always, due to randomness), the application crashes at line 384 of RRTstar.cpp, in the updateChildCosts() method. This is what the error looks like from GDB:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00007fff5f3ffff8
0x00000001003827c1 in ompl::geometric::RRTstar::updateChildCosts (this=0x10200ae00, m=0x101c02240, delta=-1.7763568394002505e-15) at /Users/luis/code/ompl-0.12.1-Source/src/ompl/contrib/rrt_star/src/RRTstar.cpp:384
384 for (size_t i = 0; i < m->children.size(); ++i)

When I try to print a GDB backtrace from this line, it repeatedly and infinitely outputs this same function (updateChildCosts()), indicating that the function is infinitely recursing. This seems to indicate that there is a cycle in the RRT* graph.

FCLMethodWrapper.h out of date

Original report by Anonymous.

---

24 // FCL Headers
25 #include <fcl/BVH_model.h>
26 #include <fcl/collision.h>
27 #include <fcl/collision_node.h>
28 #include <fcl/transform.h>
29 #include <fcl/traversal_node_bvhs.h>
30 #include <fcl/simple_setup.h>
31 #include <fcl/conservative_advancement.h>

I found out that the fcl have some changes in Fuerte, it should be

// FCL Headers
#include <fcl/BVH/BVH_model.h>
#include <fcl/collision.h>
#include <fcl/collision_node.h>
#include <fcl/math/transform.h>
#include <fcl/traversal/traversal_node_bvhs.h>
#include <fcl/ccd/conservative_advancement.h>

However I can't track the <fcl/simple_setup.h> and can't install ompl.app

My system: Ubuntu 12.04 32bit ROS Fuerte

How to start after installing

Original report by anhdungbk25 (Bitbucket: anhdungbk25, ).

---

hi pro,
I have just installed ompl and omplapp on my ubuntu 12.04.
But I am really new in the motion planning, I do not know how can I start with the simple example.
I am using eclipse CDT, so can anyone show me detail how can I make a simple project C++ with eclipse and reference to ompl.
Thank you so much,

How to compute the direction to the closest environment?

Original report by Shuo Liu (Bitbucket: Ashs, GitHub: Ashs).

---

The clearance function in StateValidityChecker class only returns the distance to the nearest invalid state or check whether a direction is valid. But how to compute the direction to the nearest invalid state? I also didn't find it in the FCL and PQP collision checking libraries.
Thx.

The variable MATH

Original report by Anonymous.

---

During the compiling I get this erreur :

the fllowing variables are used in the project and they are set to NOT FOUND.
please set them and make sure that they are set and tested correctly.
MATH 
         linked by target "ccd" in directory C:/omplapp/cd-prefix/src/ccd
          linked by target "ccd" in directory C:/omplapp/cd-prefix/src/ccd

I checked the CMakeList in that directory, I found MATH which is set to NOT FOUND, any idea why could that hapend !? why MATH dosen't refere where ccd libs are installed !

problem in installation

Original report by Reza_Saidafkan (Bitbucket: Reza_Saidafkan, ).

---

hi. I got this issue during installation, calling cmake:

-- Boost version: 1.49.0
-- Found the following Boost libraries:
--   date_time
--   thread
--   program_options
--   serialization
--   filesystem
--   system
--   unit_test_framework
-- Boost version: 1.49.0
-- Found the following Boost libraries:
--   python
-- Could NOT find Python (missing:  PYTHON_LIBRARIES) 
-- checking for module 'ccd=1.4'
--   package 'ccd=1.4' not found
-- checking for module 'fcl>=0.2.7'
--   package 'fcl>=0.2.7' not found
-- CCD library not found.  Will download and compile.
-- FCL library not found.  Will download and compile.
-- checking for module 'assimp'
--   package 'assimp' not found
-- Assimp library not found.  Will download and compile.
-- Boost version: 1.49.0
-- Found the following Boost libraries:
--   python
-- Boost version: 1.49.0
-- Found the following Boost libraries:
--   python
-- Boost version: 1.49.0
-- Found the following Boost libraries:
--   python
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
PYTHON_LIBRARIES
    linked by target "py_boost_function" in directory /home/diablo/Desktop/omplapp-0.12.2-Source/ompl/tests

-- Configuring incomplete, errors occurred!

Running on Ubuntu 13.04, 3.8.0-22-generic, AMD64.
I've been struggling all the day, don't know whay to do.

Segmentation fault

Original report by surabhipandey88 (Bitbucket: surabhipandey88, ).

---

Whenever i m trying to run gui for ompl its giving segmentation fault as soon as i select the environment from the resources.

Import Error

Original report by Panagiotis Karagiannis (Bitbucket: pkaragiannis, ).

---

Hi,
I followed all the instructions to install omplapp and I did all the necessary bindings (and I followed all the instructions twice). Although it raised me many module errors(it couldn't find the modules _util,_base,_geometric etc respectivelly) when I tried to run the application I succesfully passed them. I couldn't find though one module. The error that it shows me is the following:

#!
Traceback (most recent call last):
File .../Kevraki_OMPL/omplapp/gui/ompl_app.py", line 44, in <module>
from ompl import app as oa
File .../Kevraki_OMPL/omplapp/ompl/py-bindings/ompl/app/__init__.py", line 15, in <module>
dll_loader('ompl_app', dirname(abspath(__file__)))
File .../Kevraki_OMPL/omplapp/ompl/py-bindings/ompl/__init__.py", line 27, in dll_loader
raise ImportError
ImportError

Does anyone have any idea?
Thanks in advance
Panagiotis

Problem with launching ompl gui

Original report by surabhipandey88 (Bitbucket: surabhipandey88, ).

---

Hi,
I tried to run this command make update_bindings for launching ompl gui, but error occured
make: *** No rule to make target `update_bindings'. Stop. plz help

Macports Install Error

Original report by Stephen Dunn (Bitbucket: entangledloops, GitHub: entangledloops).

---

Hi Mark,
I have installed all dependencies, but nothing seems to work on my macbook (installed on Ubuntu with no issues). I have downloaded and tried to build from source, but receive an identical error to the user here:
#5/osx-homebrew-python-bindings-not-working

I was able to follow the instructions as you suggested with no errors, but I always fail trying to update the bindings. Please let me know what you need to debug this in addition to what is below and the attached files. Thanks! (there are no spaces in the path either, running directly from ~/omplapp-0.12.2-Source/build/Release)

[ 33%] Built target update_util_bindings
[ 44%] Preparing C++ header file for Python binding generation for module base
[ 44%] Built target base.h
[ 44%] Creating C++ code for Python module base (see pyplusplus_base.log)
make[3]: *** [ompl/py-bindings/CMakeFiles/update_base_bindings] Error 1
make[2]: *** [ompl/py-bindings/CMakeFiles/update_base_bindings.dir/all] Error 2
make[1]: *** [ompl/py-bindings/CMakeFiles/update_bindings.dir/rule] Error 2
make: *** [update_bindings] Error 2

My setup:
OSX 10.8.4 - MacBook Pro Retina - Intel i7 w/16 GB DDR3

UPDATE:
Pulled latest repo. Executed the following steps:
mkdir -p build/Release
cd build/Release
cmake ../..
make installpyplusplus
cd pyplusplus/gccxml
cmake -DCMAKE_C_COMPILER=llvm-gcc-4.2 -DCMAKE_CXX_COMPILER=llvm-g++-4.2 .
make install
cd ../..
make update_bindings # fails at 75% now, ignored and continued:
sudo make -j8
sudo make test

Output from test:
The following tests FAILED:
10 - test_state_storage (Failed)
11 - test_planner_data (Failed)
17 - test_planner_data_control (Failed)
Errors while running CTest
make: *** [test] Error 8

No module named _util

Original report by Anonymous.

---

Hi!

I have been trying to install and run the Ompl-App.
After solving some unmet dependecies (OpenGL and AssImp) I am now stuck with:

python omplapp-0.11.1-Source/gui/ompl_app.py
Traceback (most recent call last):
File "omplapp-0.11.1-Source/gui/ompl_app.py", line 42, in
from ompl.util import OutputHandler, useOutputHandler, LogLevel
File "/home/hermann-local/src/omplapp/omplapp-0.11.1-Source/ompl/py-bindings/ompl/util/init.py", line 4, in
from ompl.util._util import *
ImportError: No module named _util

Any ideas?

Thanks a lot,
Andy

Segfault from python

Original report by Victor (Bitbucket: victorp28, ).

---

After a call to planer.solve(), doing the following causes a segmentation fault :

list(problem.getSolutionPath().asGeometric().getStates())

With problem being the associated ProblemDefinition object.

problems with gcc4.7 and --std=gnu++11

Original report by Devin Grady (Bitbucket: fehknt, GitHub: fehknt).

---

When compiling some code that uses OMPL with gcc4.7 with the --std=gnu++11 option (required for my code) and boost1.54, there are errors reported in some headers.
So far, I have noticed this in:
ompl/base/ProblemDefinition.h:237
ompl/control/SimpleSetup.h:136
ompl/geometric/SimpleSetup.h:136
ompl/base/src/ProblemDefinition.cpp:442

and in omplapp
benchmark/CFGBenchmark.h:54

Fixed by simply changing the implicit cast from boost ptr to bool to a .get() of the bool value.

I am still recovering information about this additional error, but after planning there is a segfault in the boost ptr stuff as well when returning from plan(). Occurs in Debug and Release builds, with TRRT and KPIECE1

#0 0x0000000000001f91 in ?? ()
#1 0x0000000000493395 in boost::checked_deleteompl::geometric::TRRT (x=0x7722b0) at /home/dkg1/include/boost/checked_delete.hpp:34
#2 0x00000000004973b0 in boost::detail::sp_counted_impl_pompl::geometric::TRRT::dispose (this=0x76fae0) at /home/dkg1/include/boost/smart_ptr/detail/sp_counted_impl.hpp:78
#3 0x0000000000489220 in boost::detail::sp_counted_base::release (this=0x76fae0) at /home/dkg1/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:146
#4 0x00000000004892af in boost::detail::shared_count::~shared_count (this=0x7fffffffc298, __in_chrg=) at /home/dkg1/include/boost/smart_ptr/detail/shared_count.hpp:371
#5 0x000000000048a718 in boost::shared_ptrompl::base::Planner::~shared_ptr (this=0x7fffffffc290, __in_chrg=) at /home/dkg1/include/boost/smart_ptr/shared_ptr.hpp:328
#6 0x0000000000485231 in plan (si=..., start=..., goal=...) at /home/dkg1/mcvi-package/problems/continuousNav/online_planning.h:266

libompl

Original report by ismail EL MOUAYNI (Bitbucket: ismail_el_mouayni, ).

---

For two week of hard work I tried to build and compile ompl, I did some modification in the cmake files, and recently I m stuck with one erreur that I couldn't solve,

During compiling, I have this message:

"CMake Error at ompl/src/ompl/cmake_install.cmake:51 (FILE):
  file INSTALL cannot find "C:/omplapp/lib/libompl.dll".
Call Stack (most recent call first):
  ompl/src/cmake_install.cmake:40 (INCLUDE)
  cmake_install.cmake:49 (INCLUDE)"

I looked ompl/src/cmake_install.cmake and at ompl/src/ompl/CMakeList, but I coudn't find a bug at the code source, I looked at C:/omplapp/lib/lib and actually I did not find the library file

Please help me, I did already spend two weeks, and time is running I m in a internship so I must progress.

Best regards technical data : Os vista family edition Compiler "MinGW" cmake2.8.10 CMD command prompt

Boost.Thread deprecated functions

Original report by Ryan Luna (Bitbucket: rluna, GitHub: rluna).

---

Since Boost 1.52, several functions in Boost.Thread have been marked as deprecated and are slated to be removed in version 1.57 (probably May 2014). Among these is boost::thread::timed_join, which is used in a variety of places throughout the library.

Replacements for the deprecated methods have existed since Boost 1.50. The obvious ways to deal with this are:

1. Change the minimum Boost version to 1.50 and update the code directly
2. Create a wrapper method for joining a thread, and conditionally compile the necessary code depending on the version of Boost used

Maybe there is a third, more preferred alternative.

See: http://www.boost.org/doc/libs/1_54_0/doc/html/thread/thread_management.html#thread.thread_management.thread.timed_join