Mark Moll avatar Mark Moll committed 6670ea7 Merge

merge from default

Comments (0)

Files changed (298)

+.registered
+.DS_Store
+~$
+\.swp$
+build/
+bin/
+lib/
+\.pcd$
+\.pyc$
+\.so$
+\.dylib$
+CMakeModules/ompl.pc
+doc/dox/api_overview.md
+doc/dox/download.md
+doc/dox/mainpage.md
+py-bindings/ompl/bindings_generator.py
+py-bindings/bindings
+py-bindings/ompl/app
+py-bindings/ompl/rrtstar
+src/external/installPyPlusPlus.bat
+src/external/installPyPlusPlus.sh
+src/ompl/config.h
+tests/BoostTestTeamCityReporter.h
+tests/resources/config.h
+_symlinks.sh$
 3f4f9d78ccd54a1488344a98638d92b14dcd4f79 0.10.2
 4926c9b62c3029cd86d76c0214e9d1b5b14e34a7 0.11.0
 3dd7a9f95bace77eb5042c9aac34dce5fa37a087 0.11.1
+98cef58fd24ff2bb8b11eb2618658fe936bfe033 0.12.0
+d6a586a120bb699c8b7c6c80662d865f390f1f65 0.12.1
+30eac1806535fcee8987ac611a502f7d6a89b508 0.12.2
 find_package(Boost COMPONENTS date_time thread serialization filesystem system program_options unit_test_framework REQUIRED)
 include_directories(${Boost_INCLUDE_DIR})
 
-find_package(Boost COMPONENTS odeint QUIET)
 if (NOT ${Boost_VERSION} LESS 104400)
   option(OMPL_ODESOLVER "Enable OMPL ODE solver classes" ON)
-  if(NOT Boost_ODEINT_FOUND)
+  if(${Boost_VERSION} LESS 105300)
     # Include bundled version of boost::odeint if it isn't installed natively
     set(ODEINT_INCLUDE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/src/external")
     include_directories("${ODEINT_INCLUDE_DIR}")
   option(OMPL_ODESOLVER "Enable OMPL ODE solver classes" OFF)
 endif()
 
+# pthread is sometimes needed, depending on OS / compiler
+find_package(Threads QUIET)
+
 enable_testing()
 
 # ODE is only needed for Open Dynamics Engine bindings
   include_directories(${TRIANGLE_INCLUDE_DIR})
 endif()
 
+# If FLANN is installed, a wrapper for its nearest neighbor data structures can be used
+find_package(flann 1.8.3 QUIET)
+if (FLANN_FOUND)
+    set(OMPL_HAVE_FLANN 1)
+    include_directories("${FLANN_INCLUDE_DIRS}")
+endif()
+
+add_subdirectory(py-bindings)
 add_subdirectory(src)
-add_subdirectory(py-bindings)
 add_subdirectory(tests)
 add_subdirectory(demos)
 add_subdirectory(scripts)
   add_dependencies(uninstall uninstall_links)
 endif()
 include(CPackSettings)
+
+option(OMPL_REGISTRATION "Enable one-time registration of OMPL" ON)
+if (OMPL_REGISTRATION)
+    find_file(OMPL_REGISTERED ".registered" PATHS "${CMAKE_CURRENT_SOURCE_DIR}" NO_DEFAULT_PATH)
+    if (NOT OMPL_REGISTERED)
+        file(WRITE "${CMAKE_CURRENT_SOURCE_DIR}/.registered" "")
+        find_package(Python QUIET)
+        if (PYTHON_FOUND)
+            execute_process(COMMAND "${PYTHON_EXEC}" "-m" "webbrowser" "http://ompl.kavrakilab.org/core/register.html"
+                OUTPUT_QUIET ERROR_QUIET)
+        endif()
+    endif()
+endif()

CMakeModules/CPackSettings.cmake

     "installPyPlusPlus.sh$"
     "create_symlinks.sh$"
     "uninstall_symlinks.sh$"
-    "config.h$")
+    "config.h$"
+    ".registered$"
+    "download.md$"
+    "mainpage.md$"
+    "binding_generator.py$")
 set(CPACK_SOURCE_GENERATOR "TGZ;ZIP")
 set(CPACK_GENERATOR "TGZ")
 

CMakeModules/CompilerSettings.cmake

     add_definitions(-W -Wall -Wextra -Wno-missing-field-initializers -Wno-unused)
 endif(CMAKE_COMPILER_IS_GNUCXX)
 if(CMAKE_CXX_COMPILER_ID STREQUAL "Clang")
-    add_definitions(-W -Wall -Wextra -Wno-missing-field-initializers -Wno-unused -Wno-unused-parameter -Wno-delete-non-virtual-dtor -Wno-overloaded-virtual)
+    add_definitions(-W -Wall -Wextra -Wno-missing-field-initializers -Wno-unused -Wno-unused-parameter -Wno-delete-non-virtual-dtor -Wno-overloaded-virtual -Wno-unknown-pragmas)
 endif()
 
 if(MSVC OR MSVC90 OR MSVC10)
     set(IS_ICPC 0)
 endif()
 if(IS_ICPC)
+    add_definitions(-wd191 -wd411 -wd654 -wd1125 -wd1292 -wd1565 -wd1628 -wd2196)
     set(CMAKE_AR "xiar" CACHE STRING "Intel archiver" FORCE)
     set(CMAKE_CXX_FLAGS "-pthread" CACHE STRING "Default compile flags" FORCE)
-    set(CMAKE_CXX_FLAGS_RELEASE "-fast -DNDEBUG"
+    set(CMAKE_CXX_FLAGS_RELEASE "-O3 -DNDEBUG"
     CACHE STRING "Flags used by the C++ compiler during release builds." FORCE)
     set(CMAKE_CXX_FLAGS_DEBUG "-O0 -g" CACHE STRING
     "Flags used by the C++ compiler during debug builds." FORCE)

CMakeModules/Findflann.cmake

+# Find FLANN, a Fast Library for Approximate Nearest Neighbors
+
+include(FindPackageHandleStandardArgs)
+
+find_path(FLANN_INCLUDE_DIR flann.hpp PATH_SUFFIXES flann)
+if (FLANN_INCLUDE_DIR)
+    file(READ "${FLANN_INCLUDE_DIR}/config.h" FLANN_CONFIG)
+    string(REGEX REPLACE ".*FLANN_VERSION_ \"([0-9.]+)\".*" "\\1" FLANN_VERSION ${FLANN_CONFIG})
+    if(FLANN_VERSION VERSION_LESS flann_FIND_VERSION)
+        message(STATUS "Installed version of flann is too old. Version ${flann_FIND_VERSION} or above required.")
+    else()
+        string(REGEX REPLACE "/flann$" "" FLANN_INCLUDE_DIRS ${FLANN_INCLUDE_DIR})
+    endif()
+endif()
+
+find_package_handle_standard_args(flann DEFAULT_MSG FLANN_INCLUDE_DIRS)

CMakeModules/OMPLUtils.cmake

   add_executable(${ARGV})
   target_link_libraries(${test_name}
     ompl
+    ${Boost_DATE_TIME_LIBRARY}
+    ${Boost_PROGRAM_OPTIONS_LIBRARY}
+    ${Boost_SERIALIZATION_LIBRARY}
     ${Boost_FILESYSTEM_LIBRARY}
     ${Boost_SYSTEM_LIBRARY}
-    ${Boost_THREAD_LIBRARY}
-    ${Boost_DATE_TIME_LIBRARY}
     ${Boost_UNIT_TEST_FRAMEWORK_LIBRARY})
   add_test(${test_name} ${EXECUTABLE_OUTPUT_PATH}/${test_name})
 endmacro(add_ompl_test)

CMakeModules/OMPLVersion.cmake

 # set the version in a way CMake can use
 set(OMPL_MAJOR_VERSION 0)
-set(OMPL_MINOR_VERSION 11)
-set(OMPL_PATCH_VERSION 1)
+set(OMPL_MINOR_VERSION 12)
+set(OMPL_PATCH_VERSION 2)
 set(OMPL_VERSION "${OMPL_MAJOR_VERSION}.${OMPL_MINOR_VERSION}.${OMPL_PATCH_VERSION}")
 
 # increment this when we have ABI changes
-set(OMPL_ABI_VERSION 5)
+set(OMPL_ABI_VERSION 6)
 The following dependencies are optional:
 
 * [ODE](http://ode.org) (needed to compile support for planning using the Open Dynamics Engine)
-* [Py++](https://sourceforge.net/projects/pygccxml) (version from repository, needed to generate Python bindings)
+* [Py++](https://bitbucket.org/ompl/pyplusplus) (needed to generate Python bindings)
 * [Doxygen](http://www.doxygen.org) (needed to create a local copy of the documentation at
   http://ompl.kavrakilab.org/core)
 

demos/HybridSystemPlanning.cpp

     si->getStateSpace()->copyState(result, state);
     for(int i=0; i<nsteps; i++)
     {
-        se2.setX(se2.getX() + timeStep * velocity.values[0] * cos(se2.getYaw()));
-        se2.setY(se2.getY() + timeStep * velocity.values[0] * sin(se2.getYaw()));
-        se2.setYaw(se2.getYaw() + timeStep * u[0]);
-        velocity.values[0] = velocity.values[0] + timeStep * (u[1]*gear.value);
+        se2.setX(se2.getX() + dt * velocity.values[0] * cos(se2.getYaw()));
+        se2.setY(se2.getY() + dt * velocity.values[0] * sin(se2.getYaw()));
+        se2.setYaw(se2.getYaw() + dt * u[0]);
+        velocity.values[0] = velocity.values[0] + dt * (u[1]*gear.value);
 
         // 'guards' - conditions to change gears
         if (gear.value > 0)

demos/RigidBodyPlanningWithODESolverAndControls.cpp

 }
 
 // This is a callback method invoked after numerical integration.
-void KinematicCarPostIntegration (const oc::Control* /*control*/, ob::State* result)
+void KinematicCarPostIntegration (const ob::State* /*state*/, const oc::Control* /*control*/, const double /*duration*/, ob::State *result)
 {
     // Normalize orientation between 0 and 2*pi
     ob::SO2StateSpace SO2;
 
     // Use the ODESolver to propagate the system.  Call KinematicCarPostIntegration
     // when integration has finished to normalize the orientation values.
-    oc::ODEBasicSolver<> odeSolver(ss.getSpaceInformation(), &KinematicCarODE);
-    ss.setStatePropagator(odeSolver.getStatePropagator(&KinematicCarPostIntegration));
+    oc::ODESolverPtr odeSolver(new oc::ODEBasicSolver<> (ss.getSpaceInformation(), &KinematicCarODE));
+    ss.setStatePropagator(oc::ODESolver::getStatePropagator(odeSolver, &KinematicCarPostIntegration));
 
     /// create a start state
     ob::ScopedState<ob::SE2StateSpace> start(space);

demos/RigidBodyPlanningWithODESolverAndControls.py

     # satisfied
     return spaceInformation.satisfiesBounds(state)
 
-def postProp(control, state):
-    return
-
 def plan():
     # construct the state space we are planning in
     space = ob.SE2StateSpace()
     ss.setStateValidityChecker(validityChecker)
     ode = oc.ODE(kinematicCarODE)
     odeSolver = oc.ODEBasicSolver(ss.getSpaceInformation(), ode)
-    ss.setStatePropagator(odeSolver.getStatePropagator(oc.PostPropagationEvent(postProp)))
+    propagator = oc.ODESolver.getStatePropagator(odeSolver)
+    ss.setStatePropagator(propagator)
 
     # create a start state
     start = ob.State(space)

doc/CMakeLists.txt

                 OUTPUT_VARIABLE OMPL_RELEASE_DATE
                 OUTPUT_STRIP_TRAILING_WHITESPACE)
         endif()
-        configure_file("${CMAKE_CURRENT_SOURCE_DIR}/dox/download.dox.in"
-            "${CMAKE_CURRENT_SOURCE_DIR}/dox/download.dox")
-        configure_file("${CMAKE_CURRENT_SOURCE_DIR}/dox/mainpage.dox.in"
-            "${CMAKE_CURRENT_SOURCE_DIR}/dox/mainpage.dox")
+        configure_file("${CMAKE_CURRENT_SOURCE_DIR}/dox/download.md.in"
+            "${CMAKE_CURRENT_SOURCE_DIR}/dox/download.md")
+        configure_file("${CMAKE_CURRENT_SOURCE_DIR}/dox/mainpage.md.in"
+            "${CMAKE_CURRENT_SOURCE_DIR}/dox/mainpage.md")
+        file(READ "${CMAKE_CURRENT_SOURCE_DIR}/images/ompl.svg" OMPLSVG)
+        configure_file("${CMAKE_CURRENT_SOURCE_DIR}/dox/api_overview.md.in"
+            "${CMAKE_CURRENT_SOURCE_DIR}/dox/api_overview.md")
 
         # add "doc" target if Doxygen is detected
         add_custom_target(doc
-            COMMAND ${CMAKE_COMMAND} -E remove_directory html
-            COMMAND ${DOXYGEN} "Doxyfile"
+            COMMAND ./mkdocs.sh
             WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}")
 
         # add "website" target
-# Doxyfile 1.8.1.1
+# Doxyfile 1.8.3
 
 # This file describes the settings to be used by the documentation system
 # doxygen (www.doxygen.org) for a project.
 # only done if one of the specified strings matches the left-hand part of
 # the path. The tag can be used to show relative paths in the file list.
 # If left blank the directory from which doxygen is run is used as the
-# path to strip.
+# path to strip. Note that you specify absolute paths here, but also
+# relative paths, which will be relative from the directory where doxygen is
+# started.
 
 STRIP_FROM_PATH        = ..
 
 OPTIMIZE_OUTPUT_VHDL   = NO
 
 # Doxygen selects the parser to use depending on the extension of the files it
-# parses. With this tag you can assign which parser to use for a given extension.
-# Doxygen has a built-in mapping, but you can override or extend it using this
-# tag. The format is ext=language, where ext is a file extension, and language
-# is one of the parsers supported by doxygen: IDL, Java, Javascript, CSharp, C,
-# C++, D, PHP, Objective-C, Python, Fortran, VHDL, C, C++. For instance to make
-# doxygen treat .inc files as Fortran files (default is PHP), and .f files as C
-# (default is Fortran), use: inc=Fortran f=C. Note that for custom extensions
-# you also need to set FILE_PATTERNS otherwise the files are not read by doxygen.
+# parses. With this tag you can assign which parser to use for a given
+# extension. Doxygen has a built-in mapping, but you can override or extend it
+# using this tag. The format is ext=language, where ext is a file extension,
+# and language is one of the parsers supported by doxygen: IDL, Java,
+# Javascript, CSharp, C, C++, D, PHP, Objective-C, Python, Fortran, VHDL, C,
+# C++. For instance to make doxygen treat .inc files as Fortran files (default
+# is PHP), and .f files as C (default is Fortran), use: inc=Fortran f=C. Note
+# that for custom extensions you also need to set FILE_PATTERNS otherwise the
+# files are not read by doxygen.
 
 EXTENSION_MAPPING      =
 
 
 MARKDOWN_SUPPORT       = YES
 
+# When enabled doxygen tries to link words that correspond to documented classes,
+# or namespaces to their corresponding documentation. Such a link can be
+# prevented in individual cases by by putting a % sign in front of the word or
+# globally by setting AUTOLINK_SUPPORT to NO.
+
+AUTOLINK_SUPPORT       = YES
+
 # If you use STL classes (i.e. std::string, std::vector, etc.) but do not want
 # to include (a tag file for) the STL sources as input, then you should
 # set this tag to YES in order to let doxygen match functions declarations and
 
 SIP_SUPPORT            = NO
 
-# For Microsoft's IDL there are propget and propput attributes to indicate getter
-# and setter methods for a property. Setting this option to YES (the default)
-# will make doxygen replace the get and set methods by a property in the
-# documentation. This will only work if the methods are indeed getting or
+# For Microsoft's IDL there are propget and propput attributes to indicate
+# getter and setter methods for a property. Setting this option to YES (the
+# default) will make doxygen replace the get and set methods by a property in
+# the documentation. This will only work if the methods are indeed getting or
 # setting a simple type. If this is not the case, or you want to show the
 # methods anyway, you should set this option to NO.
 
 
 EXTRACT_PRIVATE        = NO
 
-# If the EXTRACT_PACKAGE tag is set to YES all members with package or internal scope will be included in the documentation.
+# If the EXTRACT_PACKAGE tag is set to YES all members with package or internal
+# scope will be included in the documentation.
 
 EXTRACT_PACKAGE        = NO
 
 GENERATE_DEPRECATEDLIST= YES
 
 # The ENABLED_SECTIONS tag can be used to enable conditional
-# documentation sections, marked by \if sectionname ... \endif.
+# documentation sections, marked by \if section-label ... \endif
+# and \cond section-label ... \endcond blocks.
 
 ENABLED_SECTIONS       =
 
 # requires the bibtex tool to be installed. See also
 # http://en.wikipedia.org/wiki/BibTeX for more info. For LaTeX the style
 # of the bibliography can be controlled using LATEX_BIB_STYLE. To use this
-# feature you need bibtex and perl available in the search path.
+# feature you need bibtex and perl available in the search path. Do not use
+# file names with spaces, bibtex cannot handle them.
 
 CITE_BIB_FILES         =
 
 # *.hxx *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.dox *.py
 # *.f90 *.f *.for *.vhd *.vhdl
 
-FILE_PATTERNS          = *.h *.cpp *.dox *.py *.cmake
+FILE_PATTERNS          = *.h \
+                         *.cpp \
+                         *.dox \
+                         *.py \
+                         *.cmake \
+                         *.md
 
 # The RECURSIVE tag can be used to turn specify whether or not subdirectories
 # should be searched for input files as well. Possible values are YES and NO.
 # against the file with absolute path, so to exclude all test directories
 # for example use the pattern */test/*
 
-EXCLUDE_PATTERNS       =
+EXCLUDE_PATTERNS       = */contrib/*/py-bindings
 
 # The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
 # (namespaces, classes, functions, etc.) that should be excluded from the
 
 FILTER_SOURCE_PATTERNS =
 
+# If the USE_MD_FILE_AS_MAINPAGE tag refers to the name of a markdown file that
+# is part of the input, its contents will be placed on the main page (index.html).
+# This can be useful if you have a project on for instance GitHub and want reuse
+# the introduction page also for the doxygen output.
+
+USE_MDFILE_AS_MAINPAGE =
+
 #---------------------------------------------------------------------------
 # configuration options related to source browsing
 #---------------------------------------------------------------------------
 
 # The HTML_STYLESHEET tag can be used to specify a user-defined cascading
 # style sheet that is used by each HTML page. It can be used to
-# fine-tune the look of the HTML output. If the tag is left blank doxygen
-# will generate a default style sheet. Note that doxygen will try to copy
-# the style sheet file to the HTML output directory, so don't put your own
-# style sheet in the HTML output directory as well, or it will be erased!
+# fine-tune the look of the HTML output. If left blank doxygen will
+# generate a default style sheet. Note that it is recommended to use
+# HTML_EXTRA_STYLESHEET instead of this one, as it is more robust and this
+# tag will in the future become obsolete.
 
 HTML_STYLESHEET        =
 
+# The HTML_EXTRA_STYLESHEET tag can be used to specify an additional
+# user-defined cascading style sheet that is included after the standard
+# style sheets created by doxygen. Using this option one can overrule
+# certain style aspects. This is preferred over using HTML_STYLESHEET
+# since it does not replace the standard style sheet and is therefor more
+# robust against future updates. Doxygen will copy the style sheet file to
+# the output directory.
+
+HTML_EXTRA_STYLESHEET  =
+
 # The HTML_EXTRA_FILES tag can be used to specify one or more extra images or
 # other source files which should be copied to the HTML output directory. Note
 # that these files will be copied to the base HTML output directory. Use the
 
 DOCSET_BUNDLE_ID       = org.kavrakilab.ompl
 
-# When GENERATE_PUBLISHER_ID tag specifies a string that should uniquely identify
-# the documentation publisher. This should be a reverse domain-name style
-# string, e.g. com.mycompany.MyDocSet.documentation.
+# When GENERATE_PUBLISHER_ID tag specifies a string that should uniquely
+# identify the documentation publisher. This should be a reverse domain-name
+# style string, e.g. com.mycompany.MyDocSet.documentation.
 
 DOCSET_PUBLISHER_ID    = org.kavrakilab
 
 
 USE_MATHJAX            = NO
 
+# When MathJax is enabled you can set the default output format to be used for
+# thA MathJax output. Supported types are HTML-CSS, NativeMML (i.e. MathML) and
+# SVG. The default value is HTML-CSS, which is slower, but has the best
+# compatibility.
+
+MATHJAX_FORMAT         = HTML-CSS
+
 # When MathJax is enabled you need to specify the location relative to the
 # HTML output directory using the MATHJAX_RELPATH option. The destination
 # directory should contain the MathJax.js script. For instance, if the mathjax
 SEARCHENGINE           = YES
 
 # When the SERVER_BASED_SEARCH tag is enabled the search engine will be
-# implemented using a PHP enabled web server instead of at the web client
-# using Javascript. Doxygen will generate the search PHP script and index
-# file to put on the web server. The advantage of the server
-# based approach is that it scales better to large projects and allows
-# full text search. The disadvantages are that it is more difficult to setup
-# and does not have live searching capabilities.
+# implemented using a web server instead of a web client using Javascript.
+# There are two flavours of web server based search depending on the
+# EXTERNAL_SEARCH setting. When disabled, doxygen will generate a PHP script for
+# searching and an index file used by the script. When EXTERNAL_SEARCH is
+# enabled the indexing and searching needs to be provided by external tools.
+# See the manual for details.
 
 SERVER_BASED_SEARCH    = NO
 
+# When EXTERNAL_SEARCH is enabled doxygen will no longer generate the PHP
+# script for searching. Instead the search results are written to an XML file
+# which needs to be processed by an external indexer. Doxygen will invoke an
+# external search engine pointed to by the SEARCHENGINE_URL option to obtain
+# the search results. Doxygen ships with an example indexer (doxyindexer) and
+# search engine (doxysearch.cgi) which are based on the open source search engine
+# library Xapian. See the manual for configuration details.
+
+EXTERNAL_SEARCH        = NO
+
+# The SEARCHENGINE_URL should point to a search engine hosted by a web server
+# which will returned the search results when EXTERNAL_SEARCH is enabled.
+# Doxygen ships with an example search engine (doxysearch) which is based on
+# the open source search engine library Xapian. See the manual for configuration
+# details.
+
+SEARCHENGINE_URL       =
+
+# When SERVER_BASED_SEARCH and EXTERNAL_SEARCH are both enabled the unindexed
+# search data is written to a file for indexing by an external tool. With the
+# SEARCHDATA_FILE tag the name of this file can be specified.
+
+SEARCHDATA_FILE        = searchdata.xml
+
+# The EXTRA_SEARCH_MAPPINGS tag can be used to enable searching through other
+# doxygen projects that are not otherwise connected via tags files, but are
+# all added to the same search index. Each project needs to have a tag file set
+# via GENERATE_TAGFILE. The search mapping then maps the name of the tag file
+# to a relative location where the documentation can be found,
+# similar to the
+# TAGFILES option but without actually processing the tag file.
+# The format is: EXTRA_SEARCH_MAPPINGS = tagname1=loc1 tagname2=loc2 ...
+
+EXTRA_SEARCH_MAPPINGS  =
+
 #---------------------------------------------------------------------------
 # configuration options related to the LaTeX output
 #---------------------------------------------------------------------------
 # compilation will be performed. Macro expansion can be done in a controlled
 # way by setting EXPAND_ONLY_PREDEF to YES.
 
-MACRO_EXPANSION        = NO
+MACRO_EXPANSION        = YES
 
 # If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES
 # then the macro expansion is limited to the macros specified with the
 # undefined via #undef or recursively expanded use the := operator
 # instead of the = operator.
 
-PREDEFINED             = BOOST_VERSION=999999
+PREDEFINED             = BOOST_VERSION=999999 OMPL_HAVE_FLANN=1
 
 # If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then
 # this tag can be used to specify a list of macro names that should be expanded.
 h1 { margin-top: 1em; }
 h2 { margin-bottom: .25em; margin-top: 1em;}
 h2:first-child { margin-top: 0em; }
+h3 { margin-top: .75em; }
 
 dl.attention, dl.note {
     background-color: #f8f8ff;
 h1, h2, .title {
     font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
 }
+div.textblock p>a, div.textblock p>a:hover, div.textblock p>a:visited,
+div.textblock li>a, div.textblock li>a:hover, div.textblock li>a:visited
+{
+    font-weight: bold;
+}
 a:visited.btn-primary { color: #fff; }
 a.btn-primary small, a:visited.btn-primary small { color: #ccc; }
 span.lineno { border-right-color: #034170; }
 .navpath li { line-height: 32px; }
 iframe#externalpagewrapper { min-width:980px; width:100%; height:1600px; margin: -50px -40px 0px -40px; }
+
+#apioverview {
+    width: 940px;
+    height: 685px;
+}
+@media (max-width: 979px) {
+    #apioverview {
+        width: 724px;
+        height: 527px;
+    }
+}

doc/dox/FAQ.dox

-/**
-\page FAQ Frequently Asked Questions
-
-- Q: <em>Why are the Python bindings not built?</em>
-  <br>
-  <b>Short answer (most likely case)</b>: after running \c cmake, type “<tt>make update_bindings</tt>”.<br>
-  <b>Long answer</b>: the bindings are automatically generated by a script. You may not have all dependencies correctly installed (or detected by cmake). Check \ref installation and \ref updating_python_bindings for details on installing dependencies and the individual steps involved in creating Python bindings, respectively.
-
-- Q: <em>Why is the code I added to the OMPL source not being compiled?</em>
-  <br>
-  See \ref buildSystem. Essentially, just run \c cmake again after adding new files.
-
-- Q: <em>How do I specify collision checking for a planner?</em>
-  <br>
-  A: See \ref stateValidation "state validation".
-
-- Q: <em>Can I visualize the exploration datastructure used by a planner?</em>
-  <br>
-  A: Yes. You need to call ompl::base::Planner::getPlannerData(). This
-  will give you an instance of ompl::base::PlannerData which contains
-  all the states and the edges between them. Functionality for
-  plotting this data is however not available.
-
-- Q: <em>Can I change the state space during planning?</em>
-  <br>
-  A: No. Such changes will make the code crash.
-
-- Q: <em>Can I set the sampler to use for a planner?</em>
-  <br>
-  A: Yes. The sampler instances used by planners are allocated by
-  either ompl::base::SpaceInformation::allocStateSampler()
-  (which calls ompl::base::StateSpace::allocStateSampler()
-  under the hood) or by
-  ompl::base::SpaceInformation::allocValidStateSampler().  By default,
-  ompl::base::SpaceInformation::allocValidStateSampler() produces an
-  instance of ompl::base::UniformValidStateSampler, unless a sampler
-  allocator was specified. The simplest way to change which sampler is allocated is to specify a sampler allocator.
-  Calling ompl::base::SpaceInformation::setValidStateSamplerAllocator() allows
-  the user to do just that:
-  @code
-  #include "ompl/base/samplers/ObstacleBasedValidStateSampler.h"
-  ...
-  ompl::base::ValidStateSamplerPtr allocValidStateSampler(const ompl::base::SpaceInformation *si)
-  {
-        return ompl::base::ValidStateSamplerPtr(new ompl::base::ObstacleBasedValidStateSampler(si));
-  }
-  ...
-  ompl::base::StateSpacePtr space(...);
-  ompl::base::SpaceInformationPtr si(new ompl::base::SpaceInformation(space));
-  si->setValidStateSamplerAllocator(boost::bind(&allocValidStateSampler, _1));
-  // for simplified calls, you can also use:
-  // si->setValidStateSamplerAllocator(&allocValidStateSampler);
-  @endcode
-  The example above is similarly applicable for ompl::base::StateSamplerAllocator ompl::control::ControlSamplerAllocator, ompl::control::DirectedControlSamplerAllocator and ompl::base::PlannerAllocator.
-<br><br>
-If your question is still not answered, another good place to check is
-the <a href="http://sourceforge.net/mailarchive/forum.php?forum_name=ompl-users">mailing
-list archive</a>.
-
-
-*/
+# Frequently Asked Questions
+
+- Q: _Why are the Python bindings not built?_
+
+  __Short answer (most likely case)__: after running \c cmake, type “<tt>make update_bindings</tt>”.
+
+  __Long answer__: the bindings are automatically generated by a script. You may not have all dependencies correctly installed (or detected by cmake). Check the pages [Installation](installation.html) and [Updating Python Bindings](python.html#updating_python_bindings) for details on installing dependencies and the individual steps involved in creating Python bindings, respectively.
+
+- Q: _Why is the code I added to the OMPL source not being compiled?_
+
+  See [the OMPL Build System](buildSystem.html). Essentially, just run \c cmake again after adding new files.
+
+- Q: _How do I specify collision checking for a planner?_
+
+  A: See [page on state validation](stateValidation.html).
+
+- Q: _Can I visualize the exploration datastructure used by a planner?_
+
+  A: Yes. You need to call ompl::base::Planner::getPlannerData(). This will give you an instance of ompl::base::PlannerData which contains all the states and the edges between them. Functionality for plotting this data is however not available.
+
+- Q: _Can I change the state space during planning?_
+
+  A: No. Such changes will make the code crash.
+
+- Q: _Can I set the sampler to use for a planner?_
+
+  A: Yes. The sampler instances used by planners are allocated by either ompl::base::SpaceInformation::allocStateSampler() (which calls ompl::base::StateSpace::allocStateSampler() under the hood) or by ompl::base::SpaceInformation::allocValidStateSampler(). By default, ompl::base::SpaceInformation::allocValidStateSampler() produces an instance of ompl::base::UniformValidStateSampler, unless a sampler allocator was specified. The simplest way to change which sampler is allocated is to specify a sampler allocator. Calling ompl::base::SpaceInformation::setValidStateSamplerAllocator() allows the user to do just that:
+  ~~~{.cpp}
+  #include "ompl/base/samplers/ObstacleBasedValidStateSampler.h"
+  ...
+  ompl::base::ValidStateSamplerPtr allocValidStateSampler(const ompl::base::SpaceInformation *si)
+  {
+      return ompl::base::ValidStateSamplerPtr(new ompl::base::ObstacleBasedValidStateSampler(si));
+  }
+  ...
+  ompl::base::StateSpacePtr space(...);
+  ompl::base::SpaceInformationPtr si(new ompl::base::SpaceInformation(space));
+  si->setValidStateSamplerAllocator(boost::bind(&allocValidStateSampler, _1));
+  // for simplified calls, you can also use:
+  // si->setValidStateSamplerAllocator(&allocValidStateSampler);
+  ~~~
+
+  The example above is similarly applicable for ompl::base::StateSamplerAllocator ompl::control::ControlSamplerAllocator, ompl::control::DirectedControlSamplerAllocator and ompl::base::PlannerAllocator.
+
+If your question is still not answered, another good place to check is the [mailing list archive](http://sourceforge.net/mailarchive/forum.php?forum_name=ompl-users).

doc/dox/acknowledgements.dox

-/**
-\page acknowledgements Acknowledgements
-
-This project is supported in part by NSF CCLI grant #0920721 and a generous gift from <a href="http://www.willowgarage.com">Willow Garage</a>. The code is based on an older version of OMPL written by <a href="http://ioan.sucan.info">Ioan Șucan</a> while at Willow Garage. This project has also benefited from a number of other efforts:
-- Previous efforts by the Kavraki lab to develop a motion planning software package. The Object-Oriented System for Motion Planning (OOPSMP) in particular provided significant inspiration in the design of OMPL. We are indebted to all other Kavraki lab members, past and present, for providing code, inspiration, and feedback. Previous work by <a href="http://faculty.cua.edu/plaku/index.html">Erion Plaku</a>, <a href="http://www.cse.unr.edu/robotics/pracsys/bekris">Kostas Bekris</a>, and Andrew Ladd in particular has been influential in the design of OMPL.
-- Development of a \ref ompl_ros_interface "ROS interface to OMPL", and useful discussions with <a href="http://www.willowgarage.com/pages/people/sachin-chitta-research-scientist">Dr. Sachin Chitta</a> and <a href="http://www.willowgarage.com/pages/people/e-gil-jones">Dr. Gil Jones</a>.
-
-
-*/

doc/dox/acknowledgements.md

+#  Acknowledgements
+
+This project is supported in part by NSF CCLI grant #0920721 and a generous gift from [Willow Garage](http://www.willowgarage.com). The code is based on an older version of OMPL written by [Ioan Șucan](http://ioan.sucan.ro) while at Willow Garage. This project has also benefited from a number of other efforts:
+
+- Previous efforts by the Kavraki lab to develop a motion planning software package. The Object-Oriented System for Motion Planning (OOPSMP) in particular provided significant inspiration in the design of OMPL. We are indebted to all other Kavraki lab members, past and present, for providing code, inspiration, and feedback. Previous work by [Erion Plaku](http://faculty.cua.edu/plaku/index.html), [Kostas Bekris](http://www.cse.unr.edu/robotics/pracsys/bekris), and [Andrew Ladd](http://www.cse.unr.edu/robotics/tc-apc/andrew_ladd) in particular has been influential in the design of OMPL.
+- Development of a [ROS interface to OMPL](http://www.ros.org/wiki/ompl_ros_interface), and useful discussions with [Dr. Sachin Chitta](http://www.willowgarage.com/pages/people/sachin-chitta-research-scientist) and [Dr. Gil Jones](http://www.willowgarage.com/pages/people/e-gil-jones).

doc/dox/api_overview.dox

-/**
-\page api_overview API Overview
-
-\htmlonly
-<map name=APImap>
-<area href="classompl_1_1control_1_1ControlSampler.html" alt="ControlSampler" coords="8,19,198,79">
-<area href="classompl_1_1control_1_1DirectedControlSampler.html" alt="DirectedControlSampler" coords="8,80,198,140">
-<area href="classompl_1_1control_1_1StatePropagator.html" alt="StatePropagator" coords="8,140,198,216">
-<area href="classompl_1_1control_1_1ControlSpace.html" alt="ControlSpace" coords="229,22,409,139">
-<area href="classompl_1_1base_1_1StateSpace.html" alt="StateSpace" coords="439,24,652,141">
-<area href="classompl_1_1base_1_1StateSampler.html" alt="StateSampler" coords="684,25,867,108">
-<area href="classompl_1_1base_1_1ProjectionEvaluator.html" alt="ProjectionEvaluator" coords="684,130,867,213">
-<area href="classompl_1_1base_1_1MotionValidator.html" alt="MotionValidator" coords="12,241,199,328">
-<area href="classompl_1_1base_1_1SpaceInformation.html" alt="SpaceInformation" coords="230,240,432,330">
-<area href="classompl_1_1base_1_1StateValidityChecker.html" alt="StateValidityChecker" coords="450,238,652,328">
-<area href="classompl_1_1base_1_1ValidStateSampler.html" alt="ValidStateSampler" coords="8,335,204,407">
-<area href="classompl_1_1base_1_1Planner.html" alt="Planner" coords="21,440,189,512">
-<area href="classompl_1_1geometric_1_1SimpleSetup.html" alt="SimpleSetup" coords="232,399,432,514">
-<area href="classompl_1_1base_1_1ProblemDefinition.html" alt="ProblemDefinition" coords="451,418,655,512">
-<area href="classompl_1_1base_1_1Goal.html" alt="Goal" coords="690,441,862,512">
-<area href="classompl_1_1base_1_1Path.html" alt="Path" coords="680,320,867,417">
-</map>
-<img src="../images/ompl.png" class="nofloat" usemap="#APImap"><hr class="space">\endhtmlonly
-
-The class ownership diagram above shows the relationship between the essential base classes in OMPL. For example, @b SpaceInformation owns a @b StateSpace; @b Planner does @e not own @b SpaceInformation, although a @b Planner does know about the @b SpaceInformation, and uses provided functionality. Users are encouraged to use the @b SimpleSetup class (ompl::geometric::SimpleSetup or ompl::control::SimpleSetup). With this class, it is only necessary to instantiate a ompl::base::StateSpace object, a ompl::control::ControlSpace object (when planning with differential constraints, i.e, planning with controls), and a ompl::base::StateValidityChecker object. Many common state spaces have already been implemented as derived @b StateSpace classes. See a list \ref availableStateSpaces "here".
-
-The ompl::base::StateValidityChecker is problem-specific, so no default implementation is available. See \ref stateValidation "this document" for more information on state validity checking. For more advanced definitions of goals, see \ref goalRepresentation "this document".
-
-\par Doxygen-generated documentation
-<ul>
-<li><a href="namespaces.html">Namespace List</a></li>
-<li><a href="annotated.html">Class List</a></li>
-</ul>
-
-\par Thread safety
-All static, non-member or const member functions are thread
-safe. Calling member functions that are not const in multiple
-threads simultaneously is unsafe and locks should be used.
-
-\par Memory management
-For all base classes @b Class, a @b ClassPtr type is defined as
-well. @b ClassPtr is in fact a <a
-href="http://wiki.inkscape.org/wiki/index.php/Boost_shared_pointers">boost
-shared pointer</a> for @b Class :
-@code
-class Class;
-typedef boost::shared_ptr<Class> ClassPtr;
-@endcode
-The code above is generated by the ClassForward macro defined in ompl/util/ClassForward.h:
-@code
-ClassForward(Class);
-@endcode
-Often the user is required to operate with @b *Ptr variables, in order
-to ensure all memory is freed at the termination of the program
-without explicitly calling \c delete. For some classes internal to the
-library, a C-style pointer is maintained instead of the @b *Ptr
-variable to avoid cyclic dependencies (which prevent memory
-de-allocation).
-
-*/

doc/dox/api_overview.md.in

+# API Overview
+
+\htmlonly
+@OMPLSVG@
+\endhtmlonly
+
+The class ownership diagram above shows the relationship between the essential base classes in OMPL. For example, __SpaceInformation__ owns a __StateSpace__; __Planner__ does _not_ own __SpaceInformation__, although a __Planner__ does know about the __SpaceInformation__, and uses provided functionality. Users are encouraged to use the __SimpleSetup__ class (ompl::geometric::SimpleSetup or ompl::control::SimpleSetup). With this class, it is only necessary to instantiate a ompl::base::StateSpace object, a ompl::control::ControlSpace object (when planning with differential constraints, i.e, planning with controls), and a ompl::base::StateValidityChecker object. Many common state spaces have already been implemented as derived __StateSpace__ classes. See a list [here](spaces.html).
+
+The ompl::base::StateValidityChecker is problem-specific, so no default implementation is available. See [this document](stateValidation.html) for more information on state validity checking. For more advanced definitions of goals, see [this document](goalRepresentation.html).
+
+#### Doxygen-generated documentation
+
+- [Namespace List](namespaces.html)
+- [Class List](annotated.html)
+
+#### Thread safety
+All static, non-member or const member functions are thread safe. Calling member functions that are not const in multiple threads simultaneously is unsafe and locks should be used.
+
+#### Memory management
+
+For all base classes __Class__, a __ClassPtr__ type is defined as well. __ClassPtr__ is in fact a [boost shared pointer](http://wiki.inkscape.org/wiki/index.php/Boost_shared_pointers) for __Class__:
+
+~~~{.cpp}
+class Class;
+typedef boost::shared_ptr<Class> ClassPtr;
+~~~
+
+The code above is generated by the OMPL_CLASS_FORWARD macro defined in ompl/util/ClassForward.h:
+
+~~~{.cpp}
+OMPL_CLASS_FORWARD(Class);
+~~~
+
+Often the user is required to operate with \b *Ptr variables, in order to ensure all memory is freed at the termination of the program without explicitly calling \c delete. For some classes internal to the library, a C-style pointer is maintained instead of the \b *Ptr variable to avoid cyclic dependencies (which prevent memory de-allocation).

doc/dox/benchmark.dox

-/**
-\page benchmark How to benchmark planners
-
-OMPL contains a ompl::Benchmark class that facilitates solving a motion planning
-problem repeatedly with different planners, different samplers, or even
-differently configured versions of the same planning algorithm. Below, we
-will describe how you can use this class.
-
-- \ref benchmark_code
-- \ref benchmark_log
-- \ref benchmark_sample_results
-
-For a command line program for rigid body motion planning, see the <a href="http://ompl.kavrakilab.org/benchmark.html">ompl_benchmark</a> program in OMPL.app.
-For more advanced benchmarks, please see <a href="http://plannerarena.org">plannerarena.org</a>.
-
-\section benchmark_code Writing Benchmarking Code
-
-Benchmarking a set of planners on a specified problem is a simple
-task in OMPL. The steps involved are as follows:
-- Configure the benchmark problem using ompl::geometric::SimpleSetup or ompl::control::SimpleSetup
-- Create a ompl::Benchmark object that takes the problem as input
-- Add one or more planners to the benchmark
-- Optionally add events to be called before and/or after the execution of a planner
-- Run the benchmark problem a specified number of times, subject to specified time and memory limits
-.
-
-The following code snippet shows you how to do this. We will start with some initial code that you have probably already used:
-\code
-#include "ompl/tools/benchmark/Benchmark.h"
-
-// A function that matches the ompl::base::PlannerAllocator type.
-// It will be used later to allocate an instance of EST
-ompl::base::PlannerPtr myConfiguredPlanner(const ompl::base::SpaceInformationPtr &si)
-{
-    geometric::EST *est = new ompl::geometric::EST(si);
-    est->setRange(100.0);
-    return ompl::base::PlannerPtr(est);
-}
-
-// Create a state space for the space we are planning in
-ompl::geometric::SimpleSetup ss(space);
-
-// Configure the problem to solve: set start state(s)
-// and goal representation
-// Everything must be set up to the point ss.solve()
-// can be called. Setting up a planner is not needed.
-\endcode
-
-Benchmarking code starts here:
-\code
-// First we create a benchmark class:
-ompl::tools::Benchmark b(ss, "my experiment");
-
-// We add the planners to evaluate.
-b.addPlanner(base::PlannerPtr(new geometric::KPIECE1(ss.getSpaceInformation())));
-b.addPlanner(base::PlannerPtr(new geometric::RRT(ss.getSpaceInformation())));
-b.addPlanner(base::PlannerPtr(new geometric::SBL(ss.getSpaceInformation())));
-b.addPlanner(base::PlannerPtr(new geometric::LBKPIECE1(ss.getSpaceInformation())));
-// etc
-
-// For planners that we want to configure in specific ways,
-// the ompl::base::PlannerAllocator should be used:
-b.addPlannerAllocator(boost::bind(&myConfiguredPlanner, _1));
-// etc.
-
-// Now we can benchmark: 5 second time limit for each plan computation,
-// 100 MB maximum memory usage per plan computation, 50 runs for each planner
-// and true means that a text-mode progress bar should be displayed while
-// computation is running.
-ompl::tools::Benchmark::Request req;
-req.maxTime = 5.0;
-req.maxMem = 100.0;
-req.runCount = 50;
-req.displayProgress = true;
-b.benchmark(req);
-
-// This will generate a file of the form ompl_host_time.log
-b.saveResultsToFile();
-\endcode
-Adding callbacks for before and after the execution of a run is also possible:
-\code
-// Assume these functions are defined
-void optionalPreRunEvent(const base::PlannerPtr &planner)
-{
-   // do whatever configuration we want to the planner,
-   // including changing of problem definition (input states)
-   // via planner->getProblemDefinition()
-}
-
-void optionalPostRunEvent(const base::PlannerPtr &planner, tools::Benchmark::RunProperties &run)
-{
-   // do any cleanup, or set values for upcoming run (or upcoming call to the pre-run event).
-
-   // adding elements to the set of collected run properties is also possible;
-   // (the added data will be recorded in the log file)
-
-   run["some extra property name INTEGER"] = "some value";
-   // The format of added data is string key, string value pairs,
-   // with the convention that the last word in string key is one of
-   // REAL, INTEGER, BOOLEAN, STRING. (this will be the type of the field
-   // when the log file is processed and saved as a database).
-   // The values are always converted to string.
-}
-
-// After the Benchmark class is defined, the events can be optionally registered:
-b.setPreRunEvent(boost::bind(&optionalPreRunEvent, _1));
-b.setPostRunEvent(boost::bind(&optionalPostRunEvent, _1, _2));
-\endcode
-
-\section benchmark_log Processing the benchmarking log file
-
-Once the C++ code computing the results has been executed, a log
-file is generated. This contains information about the settings of
-the planners, the parameters of the problem tested on, etc.
-To visualize this information, we provide a script that parses the log files:
-\code
-scripts/benchmark_statistics.py logfile.log -d mydatabase.db
-\endcode
-This will generate a SQLite database containing the parsed data. If no
-database name is specified, the named is assumed to be benchmark.db
-Once this database is generated, we can construct plots:
-\code
-scripts/benchmark_statistics.py -d mydatabase.db -p boxplot.pdf
-\endcode
-This will generate a series of plots, one for each of the attributes described below, showing the results for each planner. \ref benchmark_sample_results "Below" we have included some sample benchmark results.
-
-If you would like to process the data in different ways, you can generate
-a dump file that you can load in a MySQL database:
-\code
-scripts/benchmark_statistics.py -d mydatabase.db -m mydump.sql
-\endcode
-The database will contain 2+<em>k</em> tables:
-- \e planners is a table that contains planner configurations
-- \e experiments is a table that contains details about conducted experiments
-- <em>k</em> tables named \e planner_<name>, one for each planner, containing measurements
-
-For more details on how to use the benchmark script, see:
-\code
-scripts/benchmark_statistics.py --help
-\endcode
-
-Collected benchmark data for each experiment:
-- <strong>name:</strong> name of experiment (optional)
-- <strong>totaltime:</strong> the total duration for conducting the experiment (seconds)
-- <strong>timelimit:</strong> the maximum time allowed for every planner execution (seconds)
-- <strong>memorylimit:</strong> the maximum memory allowed for every planner execution (MB)
-- <strong>hostname:</strong> the name of the host on which the experiment was run
-- <strong>date:</strong> the date and time when the experiment was started
-
-Collected benchmark data for each planner execution:
-- <strong>time:</strong> (real) the amount of time spent planning, in seconds
-- <strong>memory:</strong> (real) the amount of memory spent planning, in MB. Note: this may be inaccurate since memory is often freed in a lazy fashion
-- <strong>solved:</strong> (boolean) flag indicating whether the planner found a solution. Note: the solution can be approximate
-- <strong>approximate solution:</strong> (boolean) flag indicating whether the found solution is approximate (does not reach the goal, but moves towards it)
-- <strong>solution difference:</strong> (real) if the solution is approximate, this is the distance from the end-point of the found approximate solution to the actual goal
-- <strong>solution length:</strong> (real) the length of the found solution
-- <strong>solution smoothness:</strong> (real) the smoothness of the found solution (the closer to 0, the smoother the path is)
-- <strong>solution clearance:</strong> (real) the clearance of the found solution (the higher the value, the larger the distance to invalid regions)
-- <strong>solution segments:</strong> (integer) the number of segments on the solution path
-- <strong>correct solution:</strong> (boolean) flag indicating whether the found solution is correct (a separate check is conducted). This should always be true.
-- <strong>correct solution strict:</strong> (boolean) flag indicating whether the found solution is correct when checked at a finer resolution than the planner used when validating motion segments. If this is sometimes false it means that the used state validation resolution is too high (only applies when using ompl::base::DiscreteMotionValidator).
-- <strong>simplification time:</strong> (real) the time spend simplifying the solution path, in seconds
-- <strong>simplified solution length:</strong> (real) the length of the found solution after simplification
-- <strong>simplified solution smoothness:</strong> (real) the smoothness of the found solution after simplification (the closer to 0, the smoother the path is)
-- <strong>simplified solution clearance:</strong> (real) the clearance of the found solution after simplification (the higher the value, the larger the distance to invalid regions)
-- <strong>simplified solution segments:</strong> (integer) the number of segments on solution path after simplification
-- <strong>simplified correct solution:</strong> (boolean) flag indicating whether the found solution is correct after simplification. This should always be true.
-- <strong>simplified correct solution strict:</strong> (boolean) flag indicating whether the found solution is correct after simplification, when checked at a finer resolution.
-- <strong>graph states:</strong> (integer) the number of states in the constructed graph
-- <strong>graph motions:</strong> (integer) the number of edges (motions) in the constructed graph
-- <strong>valid segment fraction:</strong> (real) the fraction of segments that turned out to be valid (using ompl::base::MotionValidator) out of all the segments that were checked for validity
-- more planner-specific properties
-
-\section benchmark_sample_results Sample benchmark results
-
-Below are sample results for running benchmarks for two example problems: the “cubicles” environment and the “Twistycool” environment. The complete benchmarking program (SE3RigidBodyPlanningBenchmark.cpp), the environment and robot files are included with OMPL.app, so you can rerun the exact same benchmarks on your own machine. See the \ref gallery_omplapp "gallery" for visualizations of sample solutions to both problems. The results below were run on a recent model Apple MacBook Pro (2.66 GHz Intel Core i7, 8GB of RAM). It is important to note that none of the planner parameters were tuned; all benchmarks were run with default settings. From these results one cannot draw any firm conclusions about which planner is “better” than some other planner.
-
-These are the PDF files with plots as generated by the benchmark_statistics.py script:
-- <a href="../images/cubicles.pdf">The “cubicles” problem with default settings</a>
-- <a href="../images/Twistycool.pdf">The “Twistycool” problem with default settings</a>
-.
-The plots show comparisons between ompl::geometric::RRTConnect, ompl::geometric::RRT, ompl::geometric::BKPIECE1, ompl::geometric::LBKPIECE1, ompl::geometric::KPIECE1, ompl::geometric::SBL, ompl::geometric::EST, and ompl::geometric::PRM.
-Each planner is run 500 times with a 10 second time limit for the cubicles problem for each sampling strategy, while for the Twistycool problem each planner is run 50 times with a 60 second time limit.
-
-For integer and real-valued measurements the script will compute <a href="http://en.wikipedia.org/wiki/Box_plot">box plots</a>. For example, here is the plot for the real-valued attribute <strong>time</strong> for the cubicles environment:
-
-\htmlonly<div class="row"><img src="../images/cubicles_time.png" class="span8 offset1"></div>\endhtmlonly
-
-For boolean measurements the script will create bar charts with the percentage of \b true values. For example, here is the plot for the boolean attribute <strong>solved</strong> for the Twistycool environment, a much harder problem:
-
-\htmlonly<div class="row"><img src="../images/Twistycool_solved.png" class="span8 offset1"></div>\endhtmlonly
-
-Whenever measurements are not always available for a particular attribute, the columns for each planner are labeled with the number of runs for which no data was available. For instance, the boolean attribute <strong>correct solution</strong> is not set if a solution is not found.
-*/

doc/dox/benchmark.md

+# How to benchmark planners
+
+OMPL contains a ompl::Benchmark class that facilitates solving a motion planning problem repeatedly with different planners, different samplers, or even differently configured versions of the same planning algorithm. Below, we will describe how you can use this class.
+
+- \ref benchmark_code
+- \ref benchmark_log
+- \ref benchmark_sample_results
+
+For a command line program for rigid body motion planning, see the [ompl_benchmark](http://ompl.kavrakilab.org/benchmark.html) program in OMPL.app. For more advanced benchmarks, please see [plannerarena.org](http://plannerarena.org).
+
+# Writing benchmarking code {#benchmark_code}
+
+Benchmarking a set of planners on a specified problem is a simple task in OMPL. The steps involved are as follows:
+
+- Configure the benchmark problem using ompl::geometric::SimpleSetup or ompl::control::SimpleSetup
+- Create a ompl::Benchmark object that takes the problem as input
+- Add one or more planners to the benchmark
+- Optionally add events to be called before and/or after the execution of a planner
+- Run the benchmark problem a specified number of times, subject to specified time and memory limits
+
+The following code snippet shows you how to do this. We will start with some initial code that you have probably already used:
+
+~~~{.cpp}
+#include "ompl/tools/benchmark/Benchmark.h"
+
+// A function that matches the ompl::base::PlannerAllocator type.
+// It will be used later to allocate an instance of EST
+ompl::base::PlannerPtr myConfiguredPlanner(const ompl::base::SpaceInformationPtr &si)
+{
+    geometric::EST *est = new ompl::geometric::EST(si);
+    est->setRange(100.0);
+    return ompl::base::PlannerPtr(est);
+}
+
+// Create a state space for the space we are planning in
+ompl::geometric::SimpleSetup ss(space);
+
+// Configure the problem to solve: set start state(s)
+// and goal representation
+// Everything must be set up to the point ss.solve()
+// can be called. Setting up a planner is not needed.
+~~~
+
+Benchmarking code starts here:
+
+~~~{.cpp}
+// First we create a benchmark class:
+ompl::tools::Benchmark b(ss, "my experiment");
+
+// We add the planners to evaluate.
+b.addPlanner(base::PlannerPtr(new geometric::KPIECE1(ss.getSpaceInformation())));
+b.addPlanner(base::PlannerPtr(new geometric::RRT(ss.getSpaceInformation())));
+b.addPlanner(base::PlannerPtr(new geometric::SBL(ss.getSpaceInformation())));
+b.addPlanner(base::PlannerPtr(new geometric::LBKPIECE1(ss.getSpaceInformation())));
+// etc
+
+// For planners that we want to configure in specific ways,
+// the ompl::base::PlannerAllocator should be used:
+b.addPlannerAllocator(boost::bind(&myConfiguredPlanner, _1));
+// etc.
+
+// Now we can benchmark: 5 second time limit for each plan computation,
+// 100 MB maximum memory usage per plan computation, 50 runs for each planner
+// and true means that a text-mode progress bar should be displayed while
+// computation is running.
+ompl::tools::Benchmark::Request req;
+req.maxTime = 5.0;
+req.maxMem = 100.0;
+req.runCount = 50;
+req.displayProgress = true;
+b.benchmark(req);
+
+// This will generate a file of the form ompl_host_time.log
+b.saveResultsToFile();
+~~~
+
+Adding callbacks for before and after the execution of a run is also possible:
+
+~~~{.cpp}
+// Assume these functions are defined
+void optionalPreRunEvent(const base::PlannerPtr &planner)
+{
+    // do whatever configuration we want to the planner,
+    // including changing of problem definition (input states)
+    // via planner->getProblemDefinition()
+}
+
+void optionalPostRunEvent(const base::PlannerPtr &planner, tools::Benchmark::RunProperties &run)
+{
+    // do any cleanup, or set values for upcoming run (or upcoming call to the pre-run event).
+    
+    // adding elements to the set of collected run properties is also possible;
+    // (the added data will be recorded in the log file)
+    
+    run["some extra property name INTEGER"] = "some value";
+    // The format of added data is string key, string value pairs,
+    // with the convention that the last word in string key is one of
+    // REAL, INTEGER, BOOLEAN, STRING. (this will be the type of the field
+    // when the log file is processed and saved as a database).
+    // The values are always converted to string.
+}
+
+// After the Benchmark class is defined, the events can be optionally registered:
+b.setPreRunEvent(boost::bind(&optionalPreRunEvent, _1));
+b.setPostRunEvent(boost::bind(&optionalPostRunEvent, _1, _2));
+~~~
+
+
+# Processing the benchmarking log file {#benchmark_log}
+
+Once the C++ code computing the results has been executed, a log file is generated. This contains information
+about the settings of the planners, the parameters of the problem tested on, etc. To visualize this
+information, we provide a script that parses the log files:
+
+    ompl/scripts/benchmark_statistics.py logfile.log -d mydatabase.db
+
+This will generate a SQLite database containing the parsed data. If no database name is specified, the named is assumed to be benchmark.db Once this database is generated, we can construct plots:
+
+    ompl/scripts/benchmark_statistics.py -d mydatabase.db -p boxplot.pdf
+
+This will generate a series of plots, one for each of the attributes described below, showing the results for each planner. [Below](#benchmark_sample_results) we have included some sample benchmark results.
+
+If you would like to process the data in different ways, you can generate a dump file that you can load in a MySQL database:
+
+    ompl/scripts/benchmark_statistics.py -d mydatabase.db -m mydump.sql
+
+The database will contain 2 + _k_ tables:
+
+- _planners_ is a table that contains planner configurations
+- _experiments_ is a table that contains details about conducted experiments
+- _k_ tables named \e planner_<name>, one for each planner, containing measurements
+
+For more details on how to use the benchmark script, see:
+
+    scripts/benchmark_statistics.py --help
+
+Collected benchmark data for each experiment:
+
+- __name:__ name of experiment (optional)
+- __totaltime:__ the total duration for conducting the experiment (seconds)
+- __timelimit:__ the maximum time allowed for every planner execution (seconds)
+- __memorylimit:__ the maximum memory allowed for every planner execution (MB)
+- __hostname:__ the name of the host on which the experiment was run
+- __date:__ the date and time when the experiment was started
+
+Collected benchmark data for each planner execution:
+
+- __time:__ (real) the amount of time spent planning, in seconds
+- __memory:__ (real) the amount of memory spent planning, in MB. Note: this may be inaccurate since memory is often freed in a lazy fashion
+- __solved:__ (boolean) flag indicating whether the planner found a solution. Note: the solution can be approximate
+- __approximate solution:__ (boolean) flag indicating whether the found solution is approximate (does not reach the goal, but moves towards it)
+- __solution difference:__ (real) if the solution is approximate, this is the distance from the end-point of the found approximate solution to the actual goal
+- __solution length:__ (real) the length of the found solution
+- __solution smoothness:__ (real) the smoothness of the found solution (the closer to 0, the smoother the path is)
+- __solution clearance:__ (real) the clearance of the found solution (the higher the value, the larger the distance to invalid regions)
+- __solution segments:__ (integer) the number of segments on the solution path
+- __correct solution:__ (boolean) flag indicating whether the found solution is correct (a separate check is conducted). This should always be true.
+- __correct solution strict:__ (boolean) flag indicating whether the found solution is correct when checked at a finer resolution than the planner used when validating motion segments. If this is sometimes false it means that the used state validation resolution is too high (only applies when using ompl::base::DiscreteMotionValidator).
+- __simplification time:__ (real) the time spend simplifying the solution path, in seconds
+- __simplified solution length:__ (real) the length of the found solution after simplification
+- __simplified solution smoothness:__ (real) the smoothness of the found solution after simplification (the closer to 0, the smoother the path is)
+- __simplified solution clearance:__ (real) the clearance of the found solution after simplification (the higher the value, the larger the distance to invalid regions)
+- __simplified solution segments:__ (integer) the number of segments on solution path after simplification
+- __simplified correct solution:__ (boolean) flag indicating whether the found solution is correct after simplification. This should always be true.
+- __simplified correct solution strict:__ (boolean) flag indicating whether the found solution is correct after simplification, when checked at a finer resolution.
+- __graph states:__ (integer) the number of states in the constructed graph
+- __graph motions:__ (integer) the number of edges (motions) in the constructed graph
+- __valid segment fraction:__ (real) the fraction of segments that turned out to be valid (using ompl::base::MotionValidator) out of all the segments that were checked for validity
+- more planner-specific properties
+
+# Sample benchmark results {#benchmark_sample_results}
+
+Below are sample results for running benchmarks for two example problems: the “cubicles” environment and the “Twistycool” environment. The complete benchmarking program (SE3RigidBodyPlanningBenchmark.cpp), the environment and robot files are included with OMPL.app, so you can rerun the exact same benchmarks on your own machine. See the [gallery](gallery.html#gallery_omplapp) for visualizations of sample solutions to both problems. The results below were run on a recent model Apple MacBook Pro (2.66 GHz Intel Core i7, 8GB of RAM). It is important to note that none of the planner parameters were tuned; all benchmarks were run with default settings. From these results one cannot draw any firm conclusions about which planner is “better” than some other planner.
+
+These are the PDF files with plots as generated by the benchmark_statistics.py script:
+
+- [The “cubicles” problem with default settings](../images/cubicles.pdf)
+- [The “Twistycool” problem with default settings](../images/Twistycool.pdf)
+
+The plots show comparisons between ompl::geometric::RRTConnect, ompl::geometric::RRT, ompl::geometric::BKPIECE1, ompl::geometric::LBKPIECE1, ompl::geometric::KPIECE1, ompl::geometric::SBL, ompl::geometric::EST, and ompl::geometric::PRM. Each planner is run 500 times with a 10 second time limit for the cubicles problem for each sampling strategy, while for the Twistycool problem each planner is run 50 times with a 60 second time limit.
+
+For integer and real-valued measurements the script will compute [box plots](http://en.wikipedia.org/wiki/Box_plot). For example, here is the plot for the real-valued attribute __time__ for the cubicles environment:
+
+<div class="row"><img src="../images/cubicles_time.png" class="span8 offset1"></div>
+
+For boolean measurements the script will create bar charts with the percentage of __true__ values. For example, here is the plot for the boolean attribute __solved__ for the Twistycool environment, a much harder problem:
+
+<div class="row"><img src="../images/Twistycool_solved.png" class="span8 offset1"></div>
+
+Whenever measurements are not always available for a particular attribute, the columns for each planner are labeled with the number of runs for which no data was available. For instance, the boolean attribute __correct solution__ is not set if a solution is not found.

doc/dox/boost.dox

-/** 
-\page boost Boost Structures used in OMPL
-
-<a href="http://www.boost.org">Boost</a> provides an extension to the C++ 
-standard template library, supplying the user with many generic, cross-platform
-concepts that are easily included in the developer's program.  For users that
-are unfamiliar with Boost, this page will briefly describe the constructs from 
-the Boost library used in OMPL.  This tutorial makes no attempt to
-fully educate the user on the usage and API of the Boost library, only to give 
-a high level overview of these components and why they were chosen for OMPL.
-For further detail on Boost, please consult the extensive 
-<a href="http://www.boost.org/doc/libs/1_44_0/">Boost documentation</a> 
-directly.
-
-\attention
-OMPL requires Boost <b>version 1.44</b> or greater.
-
-\section sharedPtr Shared Pointer (boost/shared_ptr.hpp)
-The <a href="http://www.boost.org/doc/libs/1_44_0/libs/smart_ptr/
-shared_ptr.htm">shared pointer from Boost</a> provides intelligent memory 
-management for dynamically allocated objects created with the <i>new</i> 
-command.  In short, the templated shared_ptr object will delete (free) the 
-allocated memory when the pointer goes out of scope.  Since these pointers 
-utilize <a href="http://en.wikipedia.org/wiki/Reference_counting">reference 
-counting</a>, it is safe to pass them into functions or copy them; the object
-referenced by the pointer will only be destroyed when the reference count 
-goes to zero.
-
-\code
-class MyClass
-{
-   /* ... */
-   void myClassMethod (void) { /* ... */ }
-   /* ... */
-};
-
-void performComputation ()
-{
-    // Create an instance of MyClass using a shared_ptr
-    boost::shared_ptr <MyClass> myClassPtr (new MyClass ());
-
-    // Invoke methods on the object as normal
-    myClassPtr->myClassMethod ();    
-
-} // myClassPtr goes out of scope here.  The instance of MyClass will be deallocated at this point.
-\endcode
-
-In the example above, the function performComputation creates a new instance of
-MyClass but instantiates it using a shared_ptr.  Once the object is created, 
-the pointer can be used like normal (using -> or the * operators).  When the 
-function has finished execution, the object does not have to be specifically 
-deleted; the reference count on myClassPtr will decrement to zero when the 
-shared_ptr goes out of scope, triggering the automatic destruction the MyClass 
-object.
-
-The shared_ptr is used in OMPL in nearly all instances where an object is 
-created from the heap in order to mitigate memory leaks.  Most classes in OMPL 
-already have a typedef for a shared_ptr object using the <i>ClassForward</i> 
-macro.  For example, ompl::base::Planner utilizes the macro just before the 
-class declaration:
-
-\code
-ClassForward(Planner);
-\endcode
-
-which when expanded creates a forward declaration of the class <i>Planner</i>,
-and defines the type <i>PlannerPtr</i>:
-
-\code
-class Planner;
-typedef boost::shared_ptr<Planner> PlannerPtr;
-\endcode
-
-\section function Function and Bind (boost/function.hpp and boost/bind.hpp)
-<a href="http://www.boost.org/doc/libs/1_44_0/doc/html/function.html">Boost's 
-Function library</a> provides a templated wrapper for function pointers and 
-a generalized framework for <a href="http://en.wikipedia.org/wiki/Callback_
-(computer_programming)">callbacks</a>.  It is very easy to encapsulate a 
-function pointer into a single object using Boost.  Function objects are 
-templated with the first argument being the return type for the function, and
-subsequent arguments corresponding to the function's arguments.  For example, 
-assume we have a function called <i>computeMin</i> that returns the minimum 
-of two integers:
-
-\code
-int computeMin (int x, int y)
-{
-    return x < y ? x : y;
-}
-\endcode
-
-We could create a function pointer called <i>minFuncPtr</i> to the 
-<i>computeMin</i> function using C++ syntax like this:
-
-\code
-int (*minFuncPtr)(int, int) = computeMin;
-\endcode
-
-The same object type using Boost looks like this:
-
-\code
-// Using Boost's "portable" function syntax.  function2 indicates a function with 2 arguments.
-boost::function2<int, int, int> minFuncPtr (computeMin);
-\endcode
-
-In addition to improved readability and flexibility, we can also take advantage
-of the <a href="http://www.boost.org/doc/libs/1_44_0/libs/bind/bind.html">Bind 
-library</a> from Boost to create function pointers to class members 
-(not nearly as easy with standard C++ syntax), and fix one or more variables of 
-our function pointer.  In a more complex example, assume we have the class 
-Math:
-
-\code
-class Math
-{
-    /* ... */
-
-    // Return the minimum of x and y.  If x or y is below a lower bound, 
-    // return the lower bound instead.
-    int boundedMin (int x, int y, int lowerBound = 0)
-    {
-	if (x > lowerBound && y > lowerBound)
-            return (x < y) ? x : y;
-        else
-            return lowerBound;
-    }
-
-    /* ... */
-};
-\endcode
-
-If we wanted to create standard C++ function pointer to 
-<i>Math::boundedMin</i>, the code gets a little crazy:
-
-\code
-// Create a function pointer called minFuncPtr
-int (Math::*minFuncPtr)(int, int, int);
-
-// Assign the function pointer to the boundedMin method in the Math class.
-minFuncPtr = &Math::boundedMin;
-\endcode
-
-Calling the boundedMin function through the function pointer we just created
-is equally as obfuscated:
-
-\code
-// Create the Math object so that we have a method to invoke
-Math math;
-
-// Wait, what?
-int theMin = (math.*minFuncPtr)(1, 2, 0);
-\endcode
-
-Note that the function pointer and the corresponding invocation had to 
-include ALL arguments to the boundedMin method, even the default arguments.
-Since the function pointer is a type, all of the arguments supplied to the 
-function are part of the type and we cannot use the default value of 0 for 
-the lowerBound argument.  We can get around all of this by using Boost 
-Functions in conjunction with Boost's Bind library:
-
-\code
-// Create the Math object so that we have a method to invoke
-Math math;
-
-// Setup the Boost function pointer as a function that returns an int, and takes two integer arguments
-boost::function2 <int, int, int> minFuncPtr;
-
-// Initializing the function pointer to the boundedMin method of the math 
-// instance, and binding the lowerBound argument to zero.
-minFuncPtr = boost::bind (&Math::boundedMin, math, _1, _2, 0);
-
-// Invoking the function.  Much better.
-int theMin = minFuncPtr (1, 2);
-\endcode
-
-In a nutshell, boost::bind returns a function pointer to the method given in
-the first argument, using the instance ("math") supplied in the second 
-argument.  _1 and _2 indicate that the first and second arguments of the 
-boundedMin function will be supplied when the function is called.  The 
-zero is permanently bound to the function pointer as the third argument (the
-default value for "lowerBound").
-
-<a href="http://www.boost.org/doc/libs/1_44_0/doc/html/function.html">
-boost::function</a> and <a href="http://www.boost.org/doc/libs/1_44_0/libs/
-bind/bind.html">boost::bind</a> are used in OMPL whenever a callback function 
-is used to invoke methods on a global function or specific instance.  These 
-are used to improve readability of the code, as well as to simplify the use of
-callback functions across object barriers.  Also, if an uninitialized 
-Boost function pointer is accessed, a <i>bad_function_call</i> exception is 
-thrown, which is far more desirable than attempting to debug the segmentation 
-fault that would occur with a standard uninitialized C++ function pointer.
-
-\section nonCopyable NonCopyable (boost/noncopyable.hpp)
-Boost provides a base class called <a href="http://www.boost.org/doc/libs/
-1_44_0/libs/utility/utility.htm#Class_noncopyable">noncopyable</a> that classes
-can derive from in order to prevent them from being copied.  noncopyable has
-a private copy constructor and assignment operator.  Therefore, classes 
-deriving from noncopyable are prohibited from invoking these copy operations.
-Fully utilizing noncopyable is as simple as:
-
-\code
-class MyClass : boost::noncopyable
-{
-   ...
-};
-\endcode
-
-OMPL derives several classes from boost::noncopyable.  The rationale behind
-this is that these classes should never be copied anyway, either because 
-the copy mechanism is highly non-trivial, copying such an object would be
-prohibitive in terms of memory, or both.
-
-\section thread Thread (boost/thread.hpp)
-OMPL is designed to be thread-safe, meaning that most of the common API is
-reentrant (in general, any function marked as <i>const</i> is thread-safe).
-However, since OMPL is not limited to a single operating system, the creation
-and management of threads poses a complication since operating systems are free
-to choose how a developer creates and manages threads.  Thankfully, Boost 
-provides a cross-platform <a href="http://www.boost.org/doc/libs/1_44_0/doc/
-html/thread.html">Threading library</a> to take care of the operating system
-specific code behind the scenes.  boost::thread provides classes for threads 
-and mutexes that allow for multi-threaded computing and synchronization.
-
-It is very easy to create Threads in boost.  Simply create an object of type
-boost::thread, and supply it the handle to a "callable" object, or function:
-
-\code
-void threadFunction (void) { ... }
-
-// Threads start automatically on creation
-boost::thread myThread (threadFunction);
-// Wait until the thread has finished execution
-myThread.join ();
-\endcode
-\code
-void threadFunction (int someNumber, const char *aString) { ... }
-
-// Create a thread for threadFunction, and pass in some parameters
-boost::thread myThread (threadFunction, 42, "A good number");
-\endcode
-\code
-// Create an object for the Thread to operate in.  Thread calls operator () to start.
-struct ThreadStruct
-{
-    void operator () (int param1, const char *param2, const std::vector<double> &param3)
-    {
-        ...
-    }
-};
-
-// Create threaded object.
-ThreadStruct tStruct;
-// Create Thread.  Pass in three parameters.
-boost::thread myThread (tStruct, 1, "Two", std::vector <double> ());
-\endcode
-
-By using <a href="http://www.boost.org/doc/libs/1_44_0/doc/html/thread.html">
-Boost thread</a>, OMPL is able to remain operating system independent in
-multi-threaded applications, as long as the operating system employed by the
-user is supported by Boost.
-*/
+# Boost Structures used in OMPL
+
+[Boost](http://www.boost.org) provides an extension to the C++ standard template library, supplying the user with many generic, cross-platform concepts that are easily included in the developer's program. For users that are unfamiliar with Boost, this page will briefly describe the constructs from the Boost library used in OMPL. This tutorial makes no attempt to fully educate the user on the usage and API of the Boost library, only to give a high level overview of these components and why they were chosen for OMPL. For further detail on Boost, please consult the extensive [Boost documentation](http://www.boost.org/doc/libs/) directly.
+
+\attention
+OMPL requires Boost __version 1.44__ or greater.
+
+
+# Shared Pointer (boost/shared_ptr.hpp)
+
+The [shared pointer from Boost](http://www.boost.org/libs/smart_ptr/shared_ptr.htm) provides intelligent memory
+management for dynamically allocated objects created with the _new_ command. In short, the templated shared_ptr object will
+delete (free) the allocated memory when the pointer goes out of scope. Since these pointers utilize [reference counting](http://en.wikipedia.org/wiki/Reference_counting), it is safe to pass them into functions or copy them;
+the object referenced by the pointer will only be destroyed when the reference count goes to zero.
+
+~~~{.cpp}
+class MyClass
+{
+   /* ... */
+   void myClassMethod (void) { /* ... */ }
+   /* ... */
+};
+
+void performComputation ()
+{
+    // Create an instance of MyClass using a shared_ptr
+    boost::shared_ptr <MyClass> myClassPtr (new MyClass ());
+
+    // Invoke methods on the object as normal
+    myClassPtr->myClassMethod ();
+
+} // myClassPtr goes out of scope here.  The instance of MyClass will be deallocated at this point.
+~~~
+
+In the example above, the function performComputation creates a new instance of MyClass but instantiates it using a shared_ptr. Once the object is created, the pointer can be used like normal (using -> or the * operators). When the function has finished execution, the object does not have to be specifically deleted; the reference count on myClassPtr will decrement to zero when the shared_ptr goes out of scope, triggering the automatic destruction the MyClass object.
+
+The shared_ptr is used in OMPL in nearly all instances where an object is created from the heap in order to mitigate memory leaks. Most classes in OMPL already have a typedef for a shared_ptr object using the _OMPL_CLASS_FORWARD_ macro. For example, ompl::base::Planner utilizes the macro just before the class declaration:
+
+~~~{.cpp}
+OMPL_CLASS_FORWARD(Planner);
+~~~
+
+which when expanded creates a forward declaration of the class _Planner_, and defines the type _PlannerPtr_:
+
+~~~{.cpp}
+class Planner;
+typedef boost::shared_ptr<Planner> PlannerPtr;
+~~~
+
+
+# Function and Bind (boost/function.hpp and boost/bind.hpp)
+
+[Boost's Function library](http://www.boost.org/doc/libs/1_44_0/doc/html/function.html) provides a templated wrapper for function pointers and a generalized framework for [callbacks](http://en.wikipedia.org/wiki/Callback_%28computer_programming%29). It is very easy to encapsulate a function pointer into a single object using Boost. Function objects are templated with the first argument being the return type for the function, and subsequent arguments corresponding to the function's arguments. For example, assume we have a function called _computeMin_ that returns the minimum of two integers:
+
+~~~{.cpp}
+int computeMin (int x, int y)
+{
+    return x < y ? x : y;
+}
+~~~
+
+We could create a function pointer called _minFuncPtr_ to the _computeMin_ function using C++ syntax like this:
+
+~~~{.cpp}
+int (*minFuncPtr)(int, int) = computeMin;
+~~~
+
+The same object type using Boost looks like this:
+
+~~~{.cpp}
+boost::function<int(int,int)> minFuncPtr(computeMin);
+~~~
+
+In addition to improved readability and flexibility, we can also take advantage of the [Bind library](http://www.boost.org/doc/libs/1_44_0/libs/bind/bind.html) from Boost to create function pointers to class members (not nearly as easy with standard C++ syntax), and fix one or more variables of our function pointer.  In a more complex example, assume we have the class Math:
+
+~~~{.cpp}
+class Math
+{
+    /* ... */
+
+    // Return the minimum of x and y.  If x or y is below a lower bound,
+    // return the lower bound instead.
+    int boundedMin (int x, int y, int lowerBound = 0)
+    {
+	if (x > lowerBound && y > lowerBound)
+            return (x < y) ? x : y;
+        else
+            return lowerBound;
+    }
+
+    /* ... */
+};
+~~~
+
+If we wanted to create standard C++ function pointer to _Math::boundedMin_, the code gets a little crazy:
+
+~~~{.cpp}
+// Create a function pointer called minFuncPtr
+int (Math::*minFuncPtr)(int, int, int);
+
+// Assign the function pointer to the boundedMin method in the Math class.
+minFuncPtr = &Math::boundedMin;
+~~~
+
+Calling the boundedMin function through the function pointer we just created is equally as obfuscated:
+
+~~~{.cpp}
+// Create the Math object so that we have a method to invoke
+Math math;
+
+// Wait, what?
+int theMin = (math.*minFuncPtr)(1, 2, 0);
+~~~
+
+Note that the function pointer and the corresponding invocation had to include ALL arguments to the boundedMin method, even the default arguments. Since the function pointer is a type, all of the arguments supplied to the function are part of the type and we cannot use the default value of 0 for the lowerBound argument.  We can get around all of this by using Boost Functions in conjunction with Boost's Bind library:
+
+~~~{.cpp}
+// Create the Math object so that we have a method to invoke
+Math math;
+
+// Setup the Boost function pointer as a function that returns an int, and takes two integer arguments
+boost::function<int(int,int)> minFuncPtr;
+
+// Initializing the function pointer to the boundedMin method of the math 
+// instance, and binding the lowerBound argument to zero.
+minFuncPtr = boost::bind (&Math::boundedMin, math, _1, _2, 0);
+
+// Invoking the function.  Much better.
+int theMin = minFuncPtr (1, 2);
+~~~
+
+In a nutshell, boost::bind returns a function pointer to the method given in the first argument, using the instance (“math”) supplied in the second argument. _1 and _2 indicate that the first and second arguments of the boundedMin function will be supplied when the function is called. The zero is permanently bound to the function pointer as the third argument (the default value for “lowerBound”).
+
+[boost::function](http://www.boost.org/doc/libs/1_44_0/doc/html/function.html) and [boost::bind](http://www.boost.org/doc/libs/1_44_0/libs/bind/bind.html) are used in OMPL whenever a callback function is used to invoke methods on a global function or specific instance. These are used to improve readability of the code, as well as to simplify the use of callback functions across object barriers. Also, if an uninitialized Boost function pointer is accessed, a _bad_function_call_ exception is thrown, which is far more desirable than attempting to debug the segmentation fault that would occur with a standard uninitialized C++ function pointer.
+
+
+# NonCopyable (boost/noncopyable.hpp)
+
+Boost provides a base class called [noncopyable](http://www.boost.org/libs/utility/utility.htm) that classes can derive from in order to prevent them from being copied. noncopyable has a private copy constructor and assignment operator. Therefore, classes deriving from noncopyable are prohibited from invoking these copy operations. Fully utilizing noncopyable is as simple as:
+
+~~~{.cpp}
+class MyClass : boost::noncopyable
+{
+   ...
+};
+~~~
+
+OMPL derives several classes from boost::noncopyable.  The rationale behind
+this is that these classes should never be copied anyway, either because 
+the copy mechanism is highly non-trivial, copying such an object would be
+prohibitive in terms of memory, or both.
+
+
+# Thread (boost/thread.hpp)
+
+OMPL is designed to be thread-safe, meaning that most of the common API is reentrant (in general, any function marked as _const_ is thread-safe). However, since OMPL is not limited to a single operating system, the creation and management of threads poses a complication since operating systems are free to choose how a developer creates and manages threads. Thankfully, Boost provides a cross-platform [Threading library](http://www.boost.org/libs/thread) to take care of the operating system specific code behind the scenes. boost::thread provides classes for threads and mutexes that allow for multi-threaded computing and synchronization.
+
+It is very easy to create Threads in boost.  Simply create an object of type boost::thread, and supply it the handle to a "callable" object, or function:
+
+~~~{.cpp}
+void threadFunction (void) { ... }
+
+// Threads start automatically on creation
+boost::thread myThread (threadFunction);
+// Wait until the thread has finished execution
+myThread.join ();
+~~~
+
+~~~{.cpp}
+void threadFunction (int someNumber, const char *aString) { ... }
+
+// Create a thread for threadFunction, and pass in some parameters
+boost::thread myThread (threadFunction, 42, "A good number");
+~~~
+
+~~~{.cpp}
+// Create an object for the Thread to operate in.  Thread calls operator () to start.
+struct ThreadStruct
+{
+    void operator () (int param1, const char *param2, const std::vector<double> &param3)
+    {
+        ...
+    }
+};
+
+// Create threaded object.
+ThreadStruct tStruct;
+// Create Thread.  Pass in three parameters.
+boost::thread myThread (tStruct, 1, "Two", std::vector <double> ());
+~~~
+
+By using [Boost thread](http://www.boost.org/doc/libs/1_44_0/doc/html/thread.html), OMPL is able to remain operating system independent in multi-threaded applications, as long as the operating system employed by the user is supported by Boost.

doc/dox/buildSystem.dox

-/**
-\page buildSystem Integrate your own code with OMPL's build system
-
-When developing your own code that relies on OMPL, you have several options:
--# <b>Install OMPL and use your own build system</b>:
-    First, if you are installing OMPL “by hand” (i.e., not through your package manager), run the following commands in your OMPL build directory:
-    \code
-cmake -DCMAKE_INSTALL_PREFIX=/some/path
-make install
-\endcode
-    Below are the specifics for different build systems:
-    - <b>CMake</b>: For ease of use with CMake, we have included a CMake file that finds OMPL: \ref FindOMPL.cmake. This normally gets installed in the CMake module path, so if you use CMake in your own project, you can simply use this command in your CMakeLists.txt: \c find_package(OMPL). This will define the following variables:
-        - \c OMPL_FOUND - OMPL was found
-        - \c OMPL_LIBRARIES - The OMPL library
-        - \c OMPLAPP_LIBRARIES - The OMPL.app library
-        - \c OMPL_INCLUDE_DIRS - The OMPL include directory
-        .
-    - <b>Makefiles</b>: If you use Makefiles, add “\c -I/usr/local/include” (or, e.g., “\c -I${HOME}/ompl/src”) to your compile flags, and “\c -L/usr/local/lib \c -lompl” (or, e.g., “\c -L${HOME}/ompl/build/Release/lib \c -lompl”) to your link flags. The compile and link flags can also be obtained using  “\c pkg-config --cflags ompl” and  “\c pkg-config --libs ompl”, respectively.
-    - <b>Autotools</b>: Use the pkg-config autoconf macro PKG_CHECK_MODULES([OMPL],[ompl >= 0.10]). This is will define \c OMPL_LIBS and \c OMPL_CFLAGS if OMPL was found.
-    - <b>IDE's such as MS Visual Studio and Xcode</b>: consult your IDE's manual.
--# <b>Add your own code in OMPL's directory structure</b>: This option is recommend if you extend functionality of OMPL that you wish to contribute back to the OMPL project (see \ref thirdparty for details). OMPL uses <a href="http://www.cmake.org">CMake</a> for its build system. CMake can generate Makefiles and project files for many IDE's. If you create C++ code under ompl/src/ompl/[folder], <b>you need to re-run CMake.</b> CMake will detect your code if [folder] is one of the directories already included by OMPL. If you want your code to be in a different location, you should update ompl/src/ompl/CMakeLists.txt accordingly. See the \ref updating_python_bindings "Python documentation" for specific instructions on how to create python bindings for your own code.
-*/

doc/dox/buildSystem.md

+# Integrate your own code with OMPL's build system
+
+When developing your own code that relies on OMPL, you have several options:
+
+1. __Install OMPL and use your own build system:__ First, if you are installing OMPL “by hand” (i.e., not through your package manager), run the following commands in your OMPL build directory:
+   
+       cmake -DCMAKE_INSTALL_PREFIX=/some/path
+       make install
+   
+   Below are the specifics for different build systems:
+   
+   - __CMake:__ For ease of use with CMake, we have included a CMake file that finds OMPL: \ref FindOMPL.cmake. This normally gets installed in the CMake module path, so if you use CMake in your own project, you can simply use this command in your CMakeLists.txt: \c find_package(OMPL). This will define the following variables:
+
+      - \c OMPL_FOUND - OMPL was found
+      - \c OMPL_LIBRARIES - The OMPL library
+      - \c OMPLAPP_LIBRARIES - The OMPL.app library
+      - \c OMPL_INCLUDE_DIRS - The OMPL include directory
+
+   - __Makefiles:__ If you use Makefiles, add “\c -I/usr/local/include” (or, e.g., “\c -I${HOME}/ompl/src”) to your compile flags, and “\c -L/usr/local/lib \c -lompl” (or, e.g., “\c -L${HOME}/ompl/build/Release/lib \c -lompl”) to your link flags. The compile and link flags can also be obtained using  “\c pkg-config --cflags ompl” and  “\c pkg-config --libs ompl”, respectively.
+   - __Autotools:__ Use the pkg-config autoconf macro PKG_CHECK_MODULES([OMPL],[ompl >= 0.10]). This is will define \c OMPL_LIBS and \c OMPL_CFLAGS if OMPL was found.
+   - __Eclipse CDT:__ Below is a brief set of instructions for getting OMPL to work with Eclipse CDT. _These instructions have been verified to work with Eclipse Indigo with CDT_.
+
+      1. Click File -> New -> New Project.
+      2. Choose C++ Project; click Next.
+      3. Give your project a name; choose Executable -> Empty Project for type; click Next.
+      4. Click Advanced Settings to open the Properties window for your project.
+      5. Go to C/C++ Build -> Settings in the left pane.
+      6. Under the Tool Settings tab, choose Cross G++ Compiler -> Includes. To the "Include paths" section, add the location of the OMPL source tree. For example, on a Linux system with default installation path, you should use "/usr/local/include". Click Apply.
+      7. Again under the Tool Settings tab, choose Cross G++ Linker -> Libraries. To the "Libraries" section, add "ompl". To the "Library search path" section, add the location of the OMPL library files. For example, on a Linux system with default installation path, you should use "/usr/local/lib". Click Apply.
+      8. Click OK to leave the Properties window. Click Finish.
+
+   - __IDE's such as MS Visual Studio and Xcode:__ consult your IDE's manual.
+2. __Add your own code in OMPL's directory structure:__ This option is recommend if you extend functionality of OMPL that you wish to contribute back to the OMPL project (see [Third-Party Contributions](thirdparty.html) for details). OMPL uses [CMake](http://www.cmake.org) for its build system. CMake can generate Makefiles and project files for many IDE's. If you create C++ code under ompl/src/ompl/[folder], __you need to re-run CMake.__ CMake will detect your code if [folder] is one of the directories already included by OMPL. If you want your code to be in a different location, you should update ompl/src/ompl/CMakeLists.txt accordingly. See the [Python documentation](python.html#updating_python_bindings) for specific instructions on how to create python bindings for your own code.

doc/dox/citations.dox

-/**
-\page citations Citation
-
-If you use OMPL in your research, we kindly ask you to include the following citation in your publications:
-
-- Ioan A. Șucan, Mark Moll, Lydia E. Kavraki, <i>The Open Motion Planning Library,</i> IEEE Robotics & Automation Magazine, 2012. To appear. <a href="http://ompl.kavrakilab.org">http://ompl.kavrakilab.org</a>
-
-\code