Commits

Mark Moll  committed c4a2eb1

convert high-level docs to the more human-readable MarkDown format. Requires doxygen 1.8 to convert to html.

  • Participants
  • Parent commits 5c65735

Comments (0)

Files changed (78)

File 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")
 
         # 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

File doc/Doxyfile

-# Doxyfile 1.8.1.1
+# Doxyfile 1.8.2
 
 # 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
-# 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.
+# 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.
 
 IDL_PROPERTY_SUPPORT   = YES
 
 
 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
 
 # *.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.
 
 # 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
 

File doc/css/ompl.css

 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; }

File 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>.
-
-
-*/

File doc/dox/FAQ.md

+# 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).

File 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>.
-
-
-*/

File 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.info) 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).

File 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).
-
-*/

File doc/dox/api_overview.md

+# 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, __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](availableStateSpaces.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 ClassForward macro defined in ompl/util/ClassForward.h:
+~~~{.cpp}
+ClassForward(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).

File 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.
-*/

File 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+<em>k</em> 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.

File 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.
-*/

File doc/dox/boost.md

+# 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/doc/libs/1_44_0/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 _ClassForward_ macro. For example, ompl::base::Planner utilizes the macro just before the class declaration:
+~~~{.cpp}
+ClassForward(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/doc/libs/ 1_44_0/libs/utility/utility.htm#Class_noncopyable) 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/doc/libs/1_44_0/doc/ html/thread.html) 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.

File 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.
-*/

File 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.
+   - __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.

File 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
-@article{sucan2012the-open-motion-planning-library,
-	Author = {Ioan A. \c{S}ucan and Mark Moll and Lydia E. Kavraki},
-	Journal = {{IEEE} Robotics \& Automation Magazine},
-	Note = {To appear.},
-	Title = {The {O}pen {M}otion {P}lanning {L}ibrary},
-	Url = {http://ompl.kavrakilab.org},
-	Year = {2012}
-}
-\endcode
-*/

File doc/dox/citations.md

+# 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, _The Open Motion Planning Library,_ IEEE Robotics & Automation Magazine, 2012. To appear. http://ompl.kavrakilab.org
+
+~~~
+@article{sucan2012the-open-motion-planning-library,
+    Author = {Ioan A. \c{S}ucan and Mark Moll and Lydia E. Kavraki},
+    Journal = {{IEEE} Robotics \& Automation Magazine},
+    Note = {To appear.},
+    Title = {The {O}pen {M}otion {P}lanning {L}ibrary},
+    Url = {http://ompl.kavrakilab.org},
+    Year = {2012}
+}
+~~~

File doc/dox/code/mv.cpp

-   // define this class:
-   class myMotionValidator : public base::MotionValidator
-   {
-   public:
-       // implement checkMotion()
-   };
+// define this class:
+class myMotionValidator : public base::MotionValidator
+{
+public:
+    // implement checkMotion()
+};
 
-   base::SpaceInformationPtr si(space);
-   si->setMotionValidator(base::MotionValidatorPtr(new myMotionValidator(si)));
-   si->setup();
+base::SpaceInformationPtr si(space);
+si->setMotionValidator(base::MotionValidatorPtr(new myMotionValidator(si)));
+si->setup();

File doc/dox/code/svc.cpp

-   // define this class:
-   class myStateValidityCheckerClass : public base::StateValidityChecker
-   {
-   public:
-        myStateValidityCheckerClass(const base::SpaceInformationPtr &si) :
-          base::StateValidityChecker(si)
-           {
-        }
+// define this class:
+class myStateValidityCheckerClass : public base::StateValidityChecker
+{
+public:
+     myStateValidityCheckerClass(const base::SpaceInformationPtr &si) :
+       base::StateValidityChecker(si)
+        {
+     }
 
-        virtual bool isValid(const base::State *state) const
-        {
-                return ...;
-        }
-   };
-   // or this function:
-   bool myStateValidityCheckerFunction(const base::State *state)
-   {
-        return ...;
-   }
+     virtual bool isValid(const base::State *state) const
+     {
+             return ...;
+     }
+};
+// or this function:
+bool myStateValidityCheckerFunction(const base::State *state)
+{
+     return ...;
+}
 
-   base::SpaceInformationPtr si(space);
-   // either this call:
-   si->setStateValidityChecker(base::StateValidityCheckerPtr(new myStateValidityCheckerClass(si)));
-   // or this call:
-   si->setStateValidityChecker(boost::bind(&myStateValidityCheckerFunction, _1));
-   si->setStateValidityCheckingResolution(0.03); // 3%
-   si->setup();
+base::SpaceInformationPtr si(space);
+// either this call:
+si->setStateValidityChecker(base::StateValidityCheckerPtr(new myStateValidityCheckerClass(si)));
+// or this call:
+si->setStateValidityChecker(boost::bind(&myStateValidityCheckerFunction, _1));
+si->setStateValidityCheckingResolution(0.03); // 3%
+si->setup();

File doc/dox/contact.dox

-/**
-\page contact Contact Us
-
-\htmlonly<div class="row"><div class="span6">\endhtmlonly
-\section mailing_list Mailing Lists
- - Email ompl-users@lists.sourceforge.net to write to the OMPL discussion
-mailing list. You can subscribe to the list and see an archive of
-previous messages <a
-href="https://lists.sourceforge.net/lists/listinfo/ompl-users"><strong>here</strong></a>.
- - Email ompl-devel@lists.sourceforge.net to contact the developers. Please use this list only if you have questions that you feel are not appropriate for the ompl-users mailing list.
-<br/>
-
-\section bugs Reporting Bugs
-To report a bug, please click \ref bitbucketIssues "here".
-
-\htmlonly</div><div class="span6">
-<h2>Contact form</h2>
-<iframe src="php/html-contact-form.php" width="100%" height="620"></iframe></div></div>
-\endhtmlonly
-
-*/

File doc/dox/contact.md

+# Contact Us
+
+\htmlonly<div class="row"><div class="span6">\endhtmlonly
+# Mailing Lists
+ - Email ompl-users@lists.sourceforge.net to write to the OMPL discussion mailing list. You can subscribe to the list and see an archive of previous messages [here](https://lists.sourceforge.net/lists/listinfo/ompl-users).
+ - Email ompl-devel@lists.sourceforge.net to contact the developers. Please use this list only if you have questions that you feel are not appropriate for the ompl-users mailing list.
+
+# Reporting Bugs
+To report a bug, please click [here](bitbucketIssues.html).
+
+\htmlonly</div><div class="span6">
+<h2>Contact form</h2>
+<iframe src="php/html-contact-form.php" width="100%" height="620"></iframe></div></div>
+\endhtmlonly

File doc/dox/contrib.dox

-/**
-\page contrib External Contributions
-
-We welcome external contributions. If you would like us to list your contribution in our \ref thirdparty "page", please \ref contact "contact us". If you would like to include your code in OMPL, please read on. We want to make the process of contributing code as easy as possible. To this end we came up with the following guidelines:
-
--# Contributions are each stored in a separate directory in \c ompl/src/ompl/contrib. The contributors can choose a descriptive name for their directory such as their group name or the name of their algorithm. We have created a sample contribution directory in \c ompl/src/ompl/contrib/sample_contrib that you can use for your contribution. Below, we will describe the expected structure of a contribution's directory in more detail.
--# Within the contribution’s directory there are the following files / directories:
-       - \b CMakeLists.txt [required], a file that tells the CMake program how to build your code. Use the one in the sample_contrib directory as a template.
-       - \b src [required], a directory that contains C++ implementation files. The corresponding header files should be inside the sample_contrib directory itself.
-       - \b tests [required], a directory that contains testing code that demonstrates that essential bits of code are running correctly
-       - \b README.txt [required], a high-level description of the functionality of the contribution(s). This can include primary citations.
-       - \b doc [optional], additional documentation, ideally in doxygen format (analogous to the high-level OMPL documentation). Images or (short) videos are also welcome.
-       .
-All source code files must have a BSD license at the top of each file plus the names of the authors. Also, the code should contain doxygen-style documentation, so that the API documentation can be automatically generated and included in the OMPL web site.
-Finally, the code should be formatted according to the \ref styleGuide "OMPL style guide".
--# We will add a description to the \ref thirdparty "contributions page" (accessible from the “Community” menu at the top of the page) based on the content of the contribution's README.txt. It will include a proper acknowledgements of the authors. There will also be a link to the more detailed documentation generated from the files in the doc directory.
--# We will add the appropriate CMake code to \c ompl/src/ompl/CMakeLists to compile the code in a contribution’s src directory. Most likely, all that is required is the addition of just one line:
-\code
-add_subdirectory(contrib/sample_contrib)
-\endcode
--# It is possible that some people write code that simply uses OMPL as a low-level dependency. In that case, bundling that code with OMPL might not make sense, but we can still list this as contribution with links to an external web site if it is likely that users of OMPL are also likely to be interested in this code.
--# The mechanics of contributions are handled in one of two ways:
-       - Mercurial [preferred]: contributors clone the OMPL repository on bitbucket.org like so:
-\code
-$ hg clone https://bitbucket.org/ompl/ompl
-\endcode
-       Contributors should then create their own branch, add their files in the appropriate places, and either send us a “pull” request (if the repository is accessible to us) or email us a bundle (see http://www.selenic.com/mercurial/hg.1.html#bundle).
-       - tar balls / zip files / etc.: contributors just email us their files and we put them in the appropriate place.
-       .
--# In the unlikely event that the submitted code is of poor quality, we will try to suggest the changes necessary to include the contribution in OMPL. If the contributors cannot do this themselves, we reserve the right to reject the contribution.
-.
-
-*/

File doc/dox/contrib.md

+# External Contributions
+
+We welcome external contributions. If you would like us to list your contribution on our [page](thirdparty.html), please [contact us](contact.html). If you would like to include your code in OMPL, please read on. We want to make the process of contributing code as easy as possible. To this end we came up with the following guidelines:
+
+1. Contributions are each stored in a separate directory in \c ompl/src/ompl/contrib. The contributors can choose a descriptive name for their directory such as their group name or the name of their algorithm. We have created a sample contribution directory in \c ompl/src/ompl/contrib/sample_contrib that you can use for your contribution. Below, we will describe the expected structure of a contribution's directory in more detail.
+2. Within the contribution’s directory there are the following files / directories:
+   - __CMakeLists.txt__ [required], a file that tells the CMake program how to build your code. Use the one in the sample_contrib directory as a template.
+   - __src__ [required], a directory that contains C++ implementation files. The corresponding header files should be inside the sample_contrib directory itself.
+   - __tests__ [required], a directory that contains testing code that demonstrates that essential bits of code are running correctly
+   - __README.txt/README.md__ [required], a high-level description of the functionality of the contribution(s). This can include primary citations.
+   - __doc__ [optional], additional documentation, ideally in MarkDown format (analogous to the high-level OMPL documentation). Images or (short) videos are also welcome.
+
+   All source code files must have a BSD license at the top of each file plus the names of the authors. Also, the code should contain doxygen-style documentation, so that the API documentation can be automatically generated and included in the OMPL web site. Finally, the code should be formatted according to the [OMPL style guide](styleGuide.html).
+3. We will add a description to the [contributions page](thirdparty.html) (accessible from the “Community” menu at the top of the page) based on the content of the contribution's README.txt. It will include a proper acknowledgements of the authors. There will also be a link to the more detailed documentation generated from the files in the doc directory.
+4. We will add the appropriate CMake code to \c ompl/src/ompl/CMakeLists to compile the code in a contribution’s src directory. Most likely, all that is required is the addition of just one line:
+   ~~~
+   add_subdirectory(contrib/sample_contrib)
+   ~~~
+5. It is possible that some people write code that simply uses OMPL as a low-level dependency. In that case, bundling that code with OMPL might not make sense, but we can still list this as contribution with links to an external web site if it is likely that users of OMPL are also likely to be interested in this code.
+6. The mechanics of contributions are handled in one of two ways:
+       - Mercurial [preferred]: contributors clone the OMPL repository on bitbucket.org like so:
+
+             $ hg clone https://bitbucket.org/ompl/ompl
+
+         Contributors should then create their own branch, add their files in the appropriate places, and either send us a “pull” request (if the repository is accessible to us) or email us a bundle (see http://www.selenic.com/mercurial/hg.1.html#bundle).
+       - tar balls / zip files / etc.: contributors just email us their files and we put them in the appropriate place.
+7. In the unlikely event that the submitted code is of poor quality, we will try to suggest the changes necessary to include the contribution in OMPL. If the contributors cannot do this themselves, we reserve the right to reject the contribution.

File doc/dox/demos.dox

-/**
-\defgroup demos Demos
-\ingroup demos
-@{
-
-\par
-- <a href="RigidBodyPlanning_8cpp_source.html"><strong>Rigid body planning</strong></a> <a href="RigidBodyPlanning_8py_source.html"><strong>[Python version]</strong></a>.
-This demo is essentially the same example described in the first tutorial. It illustrates how to use the main classes.
-- <a href="StateSampling_8cpp_source.html"><strong>State sampling</strong></a> <a href="StateSampling_8py_source.html"><strong>[Python version]</strong></a>. This is the demo program used in the last beginner tutorial.
-- <a href="PlannerData_8py_source.html"><strong>Analyze and visualize planner data in Python</strong></a>. This demo relies on the <a href="http://projects.skewed.de/graph-tool/">graph-tool</a> package.
-- <a href="RigidBodyPlanningWithControls_8cpp_source.html"><strong>Rigid body planning with controls</strong></a> <a href="RigidBodyPlanningWithControls_8py_source.html"><strong>[Python version]</strong></a>.
-This demo shows how to perform planning under differential constraints for a simple car-like vehicle.
-- <a href="RigidBodyPlanningWithIntegrationAndControls_8cpp_source.html"><strong>Rigid body planning with integration and controls. </strong></a>
-This example extends the previous example by showing how one can plan for systems of ordinary differential equations in a generic way. This example uses simple Euler integration. For higher accuracy it is recommended to use the ODESolver class described in the next demo.
-- <a href="RigidBodyPlanningWithODESolverAndControls_8cpp_source.html"><strong>Rigid body planning with ODESolver and controls. </strong></a> <a href="RigidBodyPlanningWithODESolverAndControls_8py_source.html"><strong>[Python version]</strong></a>
-This example compares and contrasts the previous demo of planning with integration and planning using the ODESolver class, which wraps around <a href="http://odeint.org">Boost.Numeric.Odeint</a>.  Code showing the same model being planned with a user-implemented numerical integration technique as well as the ODESolver is presented.
-- <a href="HybridSystemPlanning_8cpp_source.html"><strong>Planning for a simple hybrid system. </strong></a>
-This demo shows how one could plan for a car with gears. The gear is a discrete state variable, while its pose is continuous. The car needs to make a sharp turn and is forced to change gears. This is not the best way to plan for hybrid systems, since this approach ignores completely the structure that exist in the system. Nevertheless, it demonstrates that the planners in OMPL are state space agnostic and can plan in discrete or hybrid state spaces.
-- <a href="RigidBodyPlanningWithIK_8cpp_source.html"><strong>Rigid body planning with an Inverse Kinematics solver generating goal states in a separate thread. </strong></a>
-This demo shows off two neat features of OMPL: a genetic algorithm-based Inverse Kinematics solver and a lazy goal state sampler. In a separate thread goal states are computed by the IK solver. While solving a motion planning problem, the planning algorithms select a random goal state from the ones computed so far.
-- <a href="OpenDERigidBodyPlanning_8cpp_source.html"><strong>Rigid body planning using the Open Dynamics Engine (OpenDE). </strong></a>
-When OpenDE is installed, OMPL will compile an extension that makes is easier to use OpenDE for forward propagation of models of motion. In this example, a box is pushed around in the plane from a start position to a goal position.
-- <a href="GeometricCarPlanning_8cpp_source.html"><strong>Planning for Dubins and Reeds-Shepp cars. </strong></a>
-This demo illustrates the use of the ompl::base::DubinsStateSpace and ompl::base::ReedsSheppStateSpace. The demo can solve two simple planning problems, print trajectories from the origin to a user-specified state, or print a discretized distance field.
-.
-
-@}
-
-*/

File doc/dox/demos.md

+# Demos
+
+\defgroup demos Demos
+\ingroup demos
+@{
+
+- [Rigid body planning](RigidBodyPlanning_8cpp_source.html) [[Python version]](RigidBodyPlanning_8py_source.html). This demo is essentially the same example described in the first tutorial. It illustrates how to use the main classes.
+- [State sampling](StateSampling_8cpp_source.html) [[Python version]](StateSampling_8py_source.html). This is the demo program used in the last beginner tutorial.
+- [Analyze and visualize planner data in Python.](PlannerData_8py_source.html) This demo relies on the [graph-tool](http://projects.skewed.de/graph-tool) package.
+- [Rigid body planning with controls](RigidBodyPlanningWithControls_8cpp_source.html) [[Python version]](RigidBodyPlanningWithControls_8py_source.html). This demo shows how to perform planning under differential constraints for a simple car-like vehicle.
+- [Rigid body planning with integration and controls.](RigidBodyPlanningWithIntegrationAndControls_8cpp_source.html) This example extends the previous example by showing how one can plan for systems of ordinary differential equations in a generic way. This example uses simple Euler integration. For higher accuracy it is recommended to use the ODESolver class described in the next demo.
+- [Rigid body planning with ODESolver and controls.](RigidBodyPlanningWithODESolverAndControls_8cpp_source.html)  [[Python version]](RigidBodyPlanningWithODESolverAndControls_8py_source.html) This example compares and contrasts the previous demo of planning with integration and planning using the ODESolver class, which wraps around [Boost.Numeric.Odeint](http://odeint.org).  Code showing the same model being planned with a user-implemented numerical integration technique as well as the ODESolver is presented.
+- [Planning for a simple hybrid system.](HybridSystemPlanning_8cpp_source.html) This demo shows how one could plan for a car with gears. The gear is a discrete state variable, while its pose is continuous. The car needs to make a sharp turn and is forced to change gears. This is not the best way to plan for hybrid systems, since this approach ignores completely the structure that exist in the system. Nevertheless, it demonstrates that the planners in OMPL are state space agnostic and can plan in discrete or hybrid state spaces.
+- [Rigid body planning with an Inverse Kinematics solver generating goal states in a separate thread.](RigidBodyPlanningWithIK_8cpp_source.html) This demo shows off two neat features of OMPL: a genetic algorithm-based Inverse Kinematics solver and a lazy goal state sampler. In a separate thread goal states are computed by the IK solver. While solving a motion planning problem, the planning algorithms select a random goal state from the ones computed so far.
+- [Rigid body planning using the Open Dynamics Engine (OpenDE).](OpenDERigidBodyPlanning_8cpp_source.html) When OpenDE is installed, OMPL will compile an extension that makes is easier to use OpenDE for forward propagation of models of motion. In this example, a box is pushed around in the plane from a start position to a goal position.
+- [Planning for Dubins and Reeds-Shepp cars.](GeometricCarPlanning_8cpp_source.html) This demo illustrates the use of the ompl::base::DubinsStateSpace and ompl::base::ReedsSheppStateSpace. The demo can solve two simple planning problems, print trajectories from the origin to a user-specified state, or print a discretized distance field.
+.
+
+@}

File doc/dox/developers.dox

-/**
-\page developers Developers
-
-OMPL is developed and maintained by the <a href="http://www.kavrakilab.org/">Physical and Biological Computing Group</a> at Rice University, led by <a href="http://www.cs.rice.edu/~kavraki/">Dr. Lydia Kavraki</a>. The development is coordinated by <a href="http://www.cs.rice.edu/~mmoll/">Dr. Mark Moll</a>, <a href="http://www.cs.rice.edu/~kavraki/">Dr. Lydia Kavraki</a> (Rice) and <a href="http://ioan.sucan.ro">Dr. Ioan Șucan</a> (Willow Garage, formerly Rice). Many others have contributed to OMPL as well, as can be seen below.
-
-\section devCore Core developers:
-  - <a href="http://www.cs.rice.edu/~mmoll/">Mark Moll</a>, Rice University
-  - <a href="http://ioan.sucan.ro">Ioan Șucan</a>, Willow Garage (formerly Rice University)
-  - <a href="http://kavrakilab.org/profiles/mmaly">Matt Maly</a>, Rice University
-  - <a href="http://www.ryanluna.com/">Ryan Luna</a>, Rice University
-
-\section devContrib Contributors:
-  - <a href="http://people.csail.mit.edu/aperez/www/">Alejandro Perez</a>, Seth Teller's <a href="http://rvsn.csail.mit.edu/">Robotics, Vision, and Sensor Networks Group</a>, MIT
-  - <a href="http://sertac.scripts.mit.edu/web/">Sertac Karaman</a>, Emilio Frazzoli's <a href="http://ares.lids.mit.edu/">Aerospace Robotics and Embedded Systems Laboratory</a>, MIT
-  - <a href="http://www.cse.unr.edu/robotics/pracsys/marble">James Marble</a>, Kostas Bekris' <a href="http://www.cse.unr.edu/robotics/pracsys/">Physics-aware Research for Autonomous Computational SYStems group</a>, University of Nevada, Reno
-  - <a href="http://people.csail.mit.edu/jbarry/">Jennifer Barry</a>, Leslie Pack Kaelbling and Tomás Lozano-Pérez's <a href="http://lis.csail.mit.edu/">Learning in Intelligent Systems Group</a>, MIT
-  - Elizabeth Fudge, Rice University
-  - <a href="http://www.willowgarage.com/pages/people/sachin-chitta-research-scientist">Sachin Chitta</a>, Willow Garage
-  - <a href="http://www.willowgarage.com/pages/people/e-gil-jones">Gil Jones</a>, Willow Garage
-  .
-
-Click \ref thirdparty "here" for a detailed description of the third-party contributions.
-
-
-*/

File doc/dox/developers.md

+# Developers
+
+OMPL is developed and maintained by the [Physical and Biological Computing Group](http://www.kavrakilab.org) at Rice University, led by [Dr. Lydia Kavraki](http://www.cs.rice.edu/~kavraki). The development is coordinated by [Dr. Mark Moll](http://www.cs.rice.edu/~mmoll), [Dr. Lydia Kavraki](http://www.cs.rice.edu/~kavraki) (Rice) and [Dr. Ioan Șucan](http://ioan.sucan.ro) (Willow Garage, formerly Rice). Many others have contributed to OMPL as well, as can be seen below.
+
+# Core developers:
+  - <a href="http://www.cs.rice.edu/~mmoll/">Mark Moll</a>, Rice University
+  - <a href="http://ioan.sucan.ro">Ioan Șucan</a>, Willow Garage (formerly Rice University)
+  - <a href="http://kavrakilab.org/profiles/mmaly">Matt Maly</a>, Rice University
+  - <a href="http://www.ryanluna.com/">Ryan Luna</a>, Rice University
+
+# Contributors:
+  - [Alejandro Perez](http://people.csail.mit.edu/aperez/www), Seth Teller's [Robotics, Vision, and Sensor Networks Group](http://rvsn.csail.mit.edu), MIT
+  - [Sertac Karaman](http://sertac.scripts.mit.edu/web), Emilio Frazzoli's [Aerospace Robotics and Embedded Systems Laboratory](http://ares.lids.mit.edu), MIT
+  - [James Marble](http://www.cse.unr.edu/robotics/pracsys/marble), Kostas Bekris' [Physics-aware Research for Autonomous Computational SYStems group](http://www.cse.unr.edu/robotics/pracsys), University of Nevada, Reno
+  - [Jennifer Barry](http://people.csail.mit.edu/jbarry), Leslie Pack Kaelbling and Tomás Lozano-Pérez's [Learning in Intelligent Systems Group](http://lis.csail.mit.edu), MIT
+  - Elizabeth Fudge, Rice University
+  - [Sachin Chitta](http://www.willowgarage.com/pages/people/sachin-chitta-research-scientist), Willow Garage
+  - [Gil Jones](http://www.willowgarage.com/pages/people/e-gil-jones), Willow Garage
+
+Click [here](thirdparty.html) for a detailed description of the third-party contributions.

File doc/dox/download.dox.in

-/**
-\page download Download
-
-\section download_release Releases
-
-- Get \b OMPL @OMPL_VERSION@, released @OMPL_RELEASE_DATE@ (<a href="releaseNotes.html">release notes</a>)<br>
-<a href="https://bitbucket.org/ompl/ompl/downloads/ompl-@OMPL_VERSION@-Source.tar.gz" class="btn btn-primary btn-small">TGZ</a>
-<a href="https://bitbucket.org/ompl/ompl/downloads/ompl-@OMPL_VERSION@-Source.zip" class="btn btn-primary btn-small">ZIP</a><br><br>
-- <a class="el" href="installation.html">Installation instructions</a>.<br>
-- <a class="el" href="https://bitbucket.org/ompl/ompl/downloads/">Older releases</a>. See the \ref releaseNotes "release notes" for a brief a description of changes for each release.
-.
-
-\section download_hg Source Code
-
-- The <a class="el" href="https://bitbucket.org/ompl/ompl/src">latest source</a> is available via Mercurial. For anonymous checkout use:
-\code
-$ hg clone https://bitbucket.org/ompl/ompl
-\endcode
-<br>
-- Alternatively, get a snapshot for the latest source code:<br>
-<a href="https://bitbucket.org/ompl/ompl/get/tip.tar.bz2" class="btn btn-primary btn-small">TBZ</a>
-<a href="https://bitbucket.org/ompl/ompl/get/tip.tar.gz" class="btn btn-primary btn-small">TGZ</a>
-<a href="https://bitbucket.org/ompl/ompl/get/tip.zip" class="btn btn-primary btn-small">ZIP</a><br><br>
-- <a class="el" href="installation.html">Installation instructions</a> are the same as for a release.
-.
-
-\section download_deb Debian Packages
-
-- Debian Packages are are generated periodically for \b OMPL as part of the ROS release process. On Ubuntu, you can use this:
-\code
-sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu `lsb_release -sc` main" > /etc/apt/sources.list.d/ros-latest.list'
-wget http://packages.ros.org/ros.key -O - | sudo apt-key add -
-sudo apt-get update
-sudo apt-get install ros-fuerte-ompl
-\endcode
-- The .deb files are also available on <a class="el" href="http://packages.ros.org/ros/ubuntu/pool/main/r/ros-fuerte-ompl/">http://packages.ros.org</a>.
-- Notes:
-  - The binary files are installed in /opt/ros/fuerte/, so yo will need to include that path when searching for OMPL headers and libs.
-  - The version for the .deb files is of the form \e X.Y.Z00R, where \e X.Y.Z is the most recent OMPL release version and \e R is the revision number in the Mercurial repository for that .deb file.
-  .
-.
-
-\section download_ros OMPL in ROS
-- \b OMPL is used as a system dependency in <a class="el" href="http://www.ros.org">ROS</a>, and the correct .deb file is installed automatically as needed.
-- A ROS package providing the latest version of this library is also available at:
-\code
-$ svn co https://rice-ros-pkg.svn.sourceforge.net/svnroot/rice-ros-pkg/ompl ompl
-\endcode
-
-
-*/

File doc/dox/download.md.in

+# Download
+
+# Releases
+
+- __OMPL__ @OMPL_VERSION@, released @OMPL_RELEASE_DATE@ ([release notes](releaseNotes.html))
+
+  <a href="https://bitbucket.org/ompl/ompl/downloads/ompl-@OMPL_VERSION@-Source.tar.gz" class="btn btn-primary btn-small">TGZ</a>
+  <a href="https://bitbucket.org/ompl/ompl/downloads/ompl-@OMPL_VERSION@-Source.zip" class="btn btn-primary btn-small">ZIP</a><br><br>
+- [Installation instructions.](installation.html)
+- [Older releases.](https://bitbucket.org/ompl/ompl/downloads) See the [release notes](releaseNotes.html) for a brief a description of changes for each release.
+
+
+# Source Code
+
+- The [latest source](https://bitbucket.org/ompl/ompl/src) is available via Mercurial. For anonymous checkout use:
+
+      $ hg clone https://bitbucket.org/ompl/ompl
+
+- Alternatively, get a snapshot for the latest source code:
+
+  <a href="https://bitbucket.org/ompl/ompl/get/tip.tar.bz2" class="btn btn-primary btn-small">TBZ</a>
+  <a href="https://bitbucket.org/ompl/ompl/get/tip.tar.gz" class="btn btn-primary btn-small">TGZ</a>
+  <a href="https://bitbucket.org/ompl/ompl/get/tip.zip" class="btn btn-primary btn-small">ZIP</a><br><br>
+- [Installation instructions](installation.html) are the same as for a release.
+
+
+# Debian Packages
+
+- Debian Packages are are generated periodically for __OMPL__ as part of the ROS release process. On Ubuntu, you can use this:
+
+      sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu `lsb_release -sc` main" > /etc/apt/sources.list.d/ros-latest.list'
+      wget http://packages.ros.org/ros.key -O - | sudo apt-key add -
+      sudo apt-get update
+      sudo apt-get install ros-fuerte-ompl
+
+- The .deb files are also available on [http://packages.ros.org](http://packages.ros.org/ros/ubuntu/pool/main/r/ros-fuerte-ompl).
+- Notes:
+  - The binary files are installed in /opt/ros/fuerte/, so yo will need to include that path when searching for OMPL headers and libs.
+  - The version for the .deb files is of the form _X.Y.Z00R_, where _X.Y.Z_ is the most recent OMPL release version and _R_ is the revision number in the Mercurial repository for that .deb file.
+
+
+# OMPL in ROS
+
+- __OMPL__ is used as a system dependency in [ROS](http://www.ros.org), and the correct .deb file is installed automatically as needed.
+- A ROS package providing the latest version of this library is also available at:
+
+      $ svn co https://rice-ros-pkg.svn.sourceforge.net/svnroot/rice-ros-pkg/ompl ompl

File doc/dox/education.dox

-/**
-\page education Teaching module on motion planning
-
-We aim to transform how college students learn robotics by offering a motion planning curriculum that enhances deep learning and is supported by OMPL.app, an integrated software environment. Students will be challenged to work on real-world robotics problems, and develop deeper knowledge by reflecting on and formally evaluating their results. Our intention is to scaffold learning by freeing students of tedious details and heavy programming and help them through a hands-on problem-based learning approach to develop critical thinking within robotics and outside robotics.
-
-As part of this effort, we have developed a collection of assignments that can be used in robotics classes that include a module on sampling-based planners. The assignments vary in difficulty and can be tailored to the needs of a class. They have been tested at the “Robotics Algorithms” class offered at Rice University. The current set of assignments includes:
--# An introductory assignment to simply run the OMPL.app software as-is. Students are asked to load different environments in the GUI, select different planners and different parameter settings, and start to develop some intuition for the difficulty of motion planning. Students are also asked to look at demo programs, so that they get an idea on how to solve motion planning problems programmatically.
--# A systematic comparison of motion planners. Students need to write a benchmarking program, collect performance metrics. They will learn the importance of randomness and the sensitivity to a specific motion planning problem.
--# Development of a new motion planning algorithm for dynamical systems. The students are asked to test their planner on a pendulum system and a simple car-like vehicle system and compare the performance against two planning algorithms that are already implemented in OMPL.
--# A final project on topics such as:
-  - Path clustering
-  - Path optimization (see \ref gallery_comp450 "gallery")
-  - Dynamic manipulation
-  - Centralized multi-robot planning
-  - Protein folding
-
-We are looking for educational partners to use and further develop the material. If you are interested in the lectures and assignments, please contact <a href="http://www.cs.rice.edu/~mmoll">Mark Moll</a> and <a href="http://www.cs.rice.edu/~kavraki">Lydia Kavraki</a>.
-
-\htmlonly
-<img src="../images/comp450-Fall2010.jpg" width="100%">
-<p class="centeralign">
-<b>Students from Rice University's COMP450 Algorithmic Robotics class, Fall 2010.</b>
-</p>
-\endhtmlonly
-
-*/

File doc/dox/education.md

+# Teaching module on motion planning
+
+We aim to transform how college students learn robotics by offering a motion planning curriculum that enhances deep learning and is supported by OMPL.app, an integrated software environment. Students will be challenged to work on real-world robotics problems, and develop deeper knowledge by reflecting on and formally evaluating their results. Our intention is to scaffold learning by freeing students of tedious details and heavy programming and help them through a hands-on problem-based learning approach to develop critical thinking within robotics and outside robotics.
+
+As part of this effort, we have developed a collection of assignments that can be used in robotics classes that include a module on sampling-based planners. The assignments vary in difficulty and can be tailored to the needs of a class. They have been tested at the “Robotics Algorithms” class offered at Rice University. The current set of assignments includes:
+
+1. An introductory assignment to simply run the OMPL.app software as-is. Students are asked to load different environments in the GUI, select different planners and different parameter settings, and start to develop some intuition for the difficulty of motion planning. Students are also asked to look at demo programs, so that they get an idea on how to solve motion planning problems programmatically.
+2. A systematic comparison of motion planners. Students need to write a benchmarking program, collect performance metrics. They will learn the importance of randomness and the sensitivity to a specific motion planning problem.
+3. Development of a new motion planning algorithm for dynamical systems. The students are asked to test their planner on a pendulum system and a simple car-like vehicle system and compare the performance against two planning algorithms that are already implemented in OMPL.
+4. A final project on topics such as:
+  - Path clustering
+  - Path optimization (see [gallery](gallery.html#gallery_comp450))
+  - Dynamic manipulation
+  - Centralized multi-robot planning
+  - Protein folding
+
+We are looking for educational partners to use and further develop the material. If you are interested in the lectures and assignments, please contact [Mark Moll](http://www.cs.rice.edu/~mmoll) and [Lydia Kavraki](http://www.cs.rice.edu/~kavraki).
+
+
+\htmlonly
+<img src="../images/comp450-Fall2010.jpg" width="100%">
+<p class="centeralign">
+<b>Students from Rice University's COMP450 Algorithmic Robotics class, Fall 2010.</b>
+</p>
+\endhtmlonly

File doc/dox/gallery.dox

-/**
-\page gallery Gallery
-
-\section gallery_pr2manipulation Manipulation Planning
-
-   An example of using OMPL on the PR2 from <a href="http://www.willowgarage.com/">Willow Garage</a>. The robot is asked to move the manipulate objects on the table. This demo is using the <a href="http://www.ros.org/wiki/ompl">OMPL ROS package</a>.
-
-\htmlonly
-<iframe width="560" height="315" src="http://www.youtube.com/embed/eUpvbOxrbwY" frameborder="0" allowfullscreen></iframe>
-\endhtmlonly
-
-\section ros_industrial ROS-Industrial Consortium
-
-ROS-Industrial aims to bring ROS to the industrial world. Path and motion planning, as provided by OMPL, are critical component of that. Below is brief overview of ROS-Industrial.
-
-\htmlonly
-<iframe width="560" height="315" src="http://www.youtube.com/embed/h54YzGIZFt4" frameborder="0" allowfullscreen></iframe>
-\endhtmlonly
-
-\section footstep_planning Real-time footstep planning for humanoid robots
-
-Below is a video illustrating the results of using OMPL to plan footsteps for a humanoid. The work is described in detail in:
-
-Nicolas Perrin and Olivier Stasse and Florent Lamiraux and Young J. Kim and Dinesh Manocha, Real-time footstep planning for humanoid robots among 3D obstacles using a hybrid bounding box, in <i>Proc. IEEE Conf. on Robotics and Automation</i>, 2012.
-
-The focus is not so much on OMPL, but rather a new hybrid bounding box that allows the robot to step over obstacles.
-
-\htmlonly
-<iframe width="420" height="315" src="http://www.youtube.com/embed/HNE4dMycosE" frameborder="0" allowfullscreen></iframe>
-\endhtmlonly
-
-\section gallery_ode Planning for a Car-Like Vehicle Using ODE
-
-   An example of using OMPL to plan for a robotic system simulated
-with <a href="http://sourceforge.net/projects/opende/">ODE</a>.  The
-goal is for the yellow car to reach the location of the green box
-without hitting the red box. The computation is performed using \ref
-cKPIECE1 "KPIECE". For each computed motion plan, a representation of
-the exploration data structure (a tree of motions) is also shown.
-
-\htmlonly
-<iframe width="420" height="315" src="http://www.youtube.com/embed/bX23YA-pasg" frameborder="0" allowfullscreen></iframe>
-\endhtmlonly
-
-\section gallery_omplapp Planning for Rigid Bodies Using OMPL.app
-
-Below are some rigid body motion planning problems and corresponding solutions found by OMPL.app.
-\htmlonly
-\endhtmlonly
-<b>The “cubicles” environment.</b> An L-shaped robot has to fly through a number of rooms and the “basement” to reach the goal state:<br>
-\htmlonly
-<div class="row">
-<div class="span5 offset1">
-  <img src="../images/cubicles-problem.png" width="100%">
-</div>
-<div class="span5">
-  <img src="../images/cubicles-solution.png" width="100%">
-</div>
-</div>
-\endhtmlonly
-
-<b>The “Twistycool” environment.</b> A twisted shape has to make a complex maneuver to move through a narrow passage:<br>
-\htmlonly
-<div class="row">
-<div class="span5 offset1">
-  <img src="../images/narrow-passage-problem.png" width="100%">
-</div>
-<div class="span5">
-  <img src="../images/narrow-passage-solution.png" width="100%">
-</div>
-</div>
-\endhtmlonly
-
-\section gallery_comp450 Class Project from COMP 450 on Path Optimization
-
-In Fall 2010 OMPL was used for the first time in Lydia Kavraki's Algorithmic Robotics class. Students completed several projects. For their last project they could choose from several options. Linda Hill and Yu Yun worked on path optimization. The different optimization criteria considered they considered were path length and sum of discrete path curvature sum. Minimizing the former in shorter paths, minimizing the second results in smoother paths. They used two optimization techniques specific to paths / curves: B-spline interpolation and path hybridization. Path smoothing using B-spline interpolation is shown below on the left. In path hybridization a set of (approximate) solutions to a motion planning problem is given as input, cross-over points are computed, and a new optimized path composed of path segments is found. An example of path hybridization to minimize path length is shown below on the right. In both cases the paths were in SE(3); the figures show simply the R<sup>3</sup> component.
-\htmlonly
-<div class="row">
-<div class="span6">
-  <img src="../images/bspline_cubicle_smoother.png" width="100%"><br>
-<b>Path smoothing with B-splines.</b> The input path is shown in red, the optimized output path is shown in blue.
-</div>
-<div class="span6">
-  <img src="../images/hybridization_cubicle_shorter.png" width="100%"><br>
-<b>Path shortening using path hybridization.</b> The colored paths are input, the solid black path is the optimized output path.
-</div>
-</div>
-\endhtmlonly
-
-*/

File doc/dox/gallery.md

+# Gallery
+
+# Manipulation Planning
+
+An example of using OMPL on the PR2 from [Willow Garage](http://www.willowgarage.com). The robot is asked to move the manipulate objects on the table. This demo is using the [OMPL ROS package](http://www.ros.org/wiki/ompl).
+
+\htmlonly
+<iframe width="560" height="315" src="http://www.youtube.com/embed/eUpvbOxrbwY" frameborder="0" allowfullscreen></iframe>
+\endhtmlonly
+
+# ROS-Industrial Consortium
+
+ROS-Industrial aims to bring ROS to the industrial world. Path and motion planning, as provided by OMPL, are critical component of that. Below is brief overview of ROS-Industrial.
+
+\htmlonly
+<iframe width="560" height="315" src="http://www.youtube.com/embed/h54YzGIZFt4" frameborder="0" allowfullscreen></iframe>
+\endhtmlonly
+
+# Real-time footstep planning for humanoid robots
+
+Below is a video illustrating the results of using OMPL to plan footsteps for a humanoid. The work is described in detail in:
+
+  Nicolas Perrin and Olivier Stasse and Florent Lamiraux and Young J. Kim and Dinesh Manocha, Real-time footstep planning for humanoid robots among 3D obstacles using a hybrid bounding box, in _Proc. IEEE Conf. on Robotics and Automation_, 2012.
+
+The focus is not so much on OMPL, but rather a new hybrid bounding box that allows the robot to step over obstacles.
+
+\htmlonly
+<iframe width="420" height="315" src="http://www.youtube.com/embed/HNE4dMycosE" frameborder="0" allowfullscreen></iframe>
+\endhtmlonly
+
+# Planning for a Car-Like Vehicle Using ODE
+
+An example of using OMPL to plan for a robotic system simulated with [ODE](http://sourceforge.net/projects/opende). The goal is for the yellow car to reach the location of the green box without hitting the red box. The computation is performed using \ref cKPIECE1 "KPIECE". For each computed motion plan, a representation of the exploration data structure (a tree of motions) is also shown.
+
+\htmlonly
+<iframe width="420" height="315" src="http://www.youtube.com/embed/bX23YA-pasg" frameborder="0" allowfullscreen></iframe>
+\endhtmlonly
+
+# Planning for Rigid Bodies Using OMPL.app {#gallery_omplapp}
+
+Below are some rigid body motion planning problems and corresponding solutions found by OMPL.app.
+
+__The “cubicles” environment.__ An L-shaped robot has to fly through a number of rooms and the “basement” to reach the goal state:
+\htmlonly
+<div class="row">
+<div class="span5 offset1">
+  <img src="../images/cubicles-problem.png" width="100%">
+</div>
+<div class="span5">
+  <img src="../images/cubicles-solution.png" width="100%">
+</div>
+</div>
+\endhtmlonly
+
+__The “Twistycool” environment.__ A twisted shape has to make a complex maneuver to move through a narrow passage:
+\htmlonly
+<div class="row">
+<div class="span5 offset1">
+  <img src="../images/narrow-passage-problem.png" width="100%">
+</div>
+<div class="span5">
+  <img src="../images/narrow-passage-solution.png" width="100%">
+</div>
+</div>
+\endhtmlonly