Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add OMPL as an external (isolating the boost dependency) #3413
I wish in this issue, we can discuss whether and how to bring in the sampling based motion planning into Drake.
Currently almost all motion planning in Drake is optimization based. On the other hand, there can be benefits to bring in sampling based motion planning, for at least two reasons
The immediate consumer for the sampling based planner could be
If we agree that we need a sample based planner in Drake, then we can either implement it ourselves, or use some third party library.
I list some existing third party libraries as follows.
In the MATLAB implementation of Drake, we have a bi-directional RRT planner implemented, in https://github.com/RobotLocomotion/drake/blob/master/drake/matlab/solvers/MotionPlanningTree.m.
A quick implementation of RRT-connect in C++ should not be hard. @RussTedrake , do you think in the near future, we need to support a full spectrum of sample based planners as OMPL, including PRM, RRT, RRT*, LBTRRT, etc?
Copy from email so that we can keep track of the conversation, and get more input:
i wonder if it is possible to have a check in the add_mex() cmake script to make sure that boost does not get linked in (at least not directly) with anything that will share the memory space with matlab? that might be a sufficient guard.
On Sep 14, 2016, at 10:08 AM, Jeremy Nimmer email@example.com wrote:
You can have Drake builds with Boost, or Matlab, but not both.
I have been considering adding Boost as a C++ dependency for other reasons.
On Wednesday, September 14, 2016 at 9:09:10 AM UTC-4, Grant Gould wrote:
If we would be linking in ompl, this would probable happen all over again.
I'm Cc:'ing sammy as he has a better idea than I do of the linker behaviour involved. However I suspect that we would have to find a way to make OMPL and mexfile builds mutually exclusive for this to work, or else find a way for them to live in separate process spaces.
On Wed, Sep 14, 2016 at 12:57 AM Hongkai Dai firstname.lastname@example.org wrote:
changed the title from
Sampling based motion planning
Add OMPL as an external (isolating the boost dependency)
Sep 16, 2016
@jamiesnape Hi Jamie, I am a new graduate student in Russ's group, and I will be working with Hongkai and you on integrating OMPL into Drake.
I tried to install OMPL using MacPort, as stated in the website. But I am getting the error message below:
dhcp-18-189-54-19:~ pangtao$ sudo port sync ; install ompl +app
Moreover, I believe we need to build OMPL from source, like what I did with Drake, so that we can view and modify the source files, right? But currently build from source instruction is only given for Ubuntu. Is there a way to build OMPL from source on OS X?
@jamiesnape Thanks! I am able to build OMPL following your instructions. I have a few more questions to ask.
OMPL version: 1.2.1
Info: No planner specified. Using default.
How can I visualise the output? Should I use their GUI, which seems to need to be built separately, or store the output in a file and then plot them in MATLAB?
@jamiesnape Thanks! Do you happen to know how to build their GUI? This is what happens when I am trying to run the GUI script now:
dhcp-18-189-9-111:gui pangtao$ pwd
dhcp-18-189-9-111:gui pangtao$ ./ompl_app.py
I am getting a new error after installing PyOpenGL:
dhcp-18-189-9-111:gui pangtao$ ./ompl_app.py
It would be beneficial if OMPL could remove Boost, but at first glance it would be a lot of work. For now, we could make OMPL and MATLAB mutually exclusive.
First step is to make a list of the dependencies that we need to install as additional externals. There are a lot of optional ones that may or may not add functionality that we need.
The only other option would be to use BCP http://www.boost.org/doc/libs/1_62_0/tools/bcp/doc/html/index.html to namespace and limit the amount of boost that is built for OMPL. Then you can mix it with matlab.
referenced this issue
May 8, 2017
When OMPL switched to C++11, we tried to remove much of the Boost usage. Boost.Graph and a few other Boost things are still needed.
Are OMPL's python bindings useful for Drake? By default they don't get generated, because it's painfully slow (it takes hours). This is because we don't explicitly mark parts of the API for Python bindings (using something like SWIG), but instead programmatically parse all code with CastXML and have general rules on how to generate Boost.Python code. This minimizes the effort required to update the binding code as the API evolves, but makes for a slow build process.
On OS X, you should be able to get the latest release by doing
The license is good, and at first glance the
The Boost dependency will be the question, because non-header-only Boost and MATLAB cannot co-exist. The OMPL build system declares hard dependencies on non-header-only portions of Boost (chrono, date-time, filesystem, thread, serialization, system), though with a quick code search perhaps some of those are vestigial and/or easily worked around (e.g., test-only). To the extent that the Boost use is hidden within
@hongkai-dai For a first goal, do we want to use this only in some examples and tests, or do we also imagine our installed toolbox
FYI Proof of concept at https://github.com/jwnimmer-tri/drake/tree/ompl-spike. This uses
As I understand it, though the
I do agree, though, that modularizing
@jwnimmer-tri thanks for looking into this. Currently I think OMPL will be mainly used for the manipulation task in Drake. There are two candidate manipulation scenarios that will consume OMPL
In the first scenario, the OMPL library is called in just ta example code. In the second scenario, I will write some functions in drake/solver, that will call OMPL code.
Here were the patches, for the record:
pkg_config_package( name = "ompl", modname = "ompl", )
Use it from our code:
cc_test( name = "foo", srcs = ["foo.cc"], deps = [ "@ompl", ], )
(I'll probably kill off my branch in a week or so.)
I think you can take that as a starting point, and then work on a branch to develop the features you want. I think the OMPL dependency can wait to be added to master until such a time as your new features are ready; I don't think Jamie or I need to PR it ahead of time.