Commits

Mark Moll committed 53e93a6

doc fixes

Comments (0)

Files changed (7)

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

doc/dox/api_overview.md

 <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 class ownership diagram above shows the relationship between the essential base classes in OMPL. For example, __SpaceInformation__ owns a __StateSpace__; __Planner__ does _not_ own __SpaceInformation__, although a __Planner__ does know about the __SpaceInformation__, and uses provided functionality. Users are encouraged to use the __SimpleSetup__ class (ompl::geometric::SimpleSetup or ompl::control::SimpleSetup). With this class, it is only necessary to instantiate a ompl::base::StateSpace object, a ompl::control::ControlSpace object (when planning with differential constraints, i.e, planning with controls), and a ompl::base::StateValidityChecker object. Many common state spaces have already been implemented as derived __StateSpace__ classes. See a list [here](spaces.html).
 
 The ompl::base::StateValidityChecker is problem-specific, so no default implementation is available. See [this document](stateValidation.html) for more information on state validity checking. For more advanced definitions of goals, see [this document](goalRepresentation.html).
 
 
 # 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
+The [shared pointer from Boost](http://www.boost.org/libs/smart_ptr/shared_ptr.htm) provides intelligent memory
 management for dynamically allocated objects created with the _new_ command. In short, the templated shared_ptr object will
 delete (free) the allocated memory when the pointer goes out of scope. Since these pointers utilize [reference counting](http://en.wikipedia.org/wiki/Reference_counting), it is safe to pass them into functions or copy them;
 the object referenced by the pointer will only be destroyed when the reference count goes to zero.
 
 # 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:
+Boost provides a base class called [noncopyable](http://www.boost.org/libs/utility/utility.htm) that classes can derive from in order to prevent them from being copied. noncopyable has a private copy constructor and assignment operator. Therefore, classes deriving from noncopyable are prohibited from invoking these copy operations. Fully utilizing noncopyable is as simple as:
 
 ~~~{.cpp}
 class MyClass : boost::noncopyable
 
 # 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.
+OMPL is designed to be thread-safe, meaning that most of the common API is reentrant (in general, any function marked as _const_ is thread-safe). However, since OMPL is not limited to a single operating system, the creation and management of threads poses a complication since operating systems are free to choose how a developer creates and manages threads. Thankfully, Boost provides a cross-platform [Threading library](http://www.boost.org/libs/thread) to take care of the operating system specific code behind the scenes. boost::thread provides classes for threads and mutexes that allow for multi-threaded computing and synchronization.
 
 It is very easy to create Threads in boost.  Simply create an object of type boost::thread, and supply it the handle to a "callable" object, or function:
 

doc/dox/mainpage.md.in

 
 ## Contents of This Library
 
-- OMPL contains implementations of many sampling-based algorithms such as PRM, RRT, EST, SBL, KPIECE, SyCLOP, and several variants of these planners. See [available planners](availablePlanners.html) for a complete list.
-- All these planners operate on very abstractly defined state spaces. Many commonly used [state spaces](availableStateSpaces.html) are already implemented (e.g., SE2, SE3, R<sup>n</sup>, etc.).
-- For any state space, different [state samplers](availableSamplers.html) can be used (e.g., uniform, Gaussian, obstacle based, etc.).
+- OMPL contains implementations of many sampling-based algorithms such as PRM, RRT, EST, SBL, KPIECE, SyCLOP, and several variants of these planners. See [available planners](planners.html) for a complete list.
+- All these planners operate on very abstractly defined state spaces. Many commonly used [state spaces](spaces.html) are already implemented (e.g., SE2, SE3, R<sup>n</sup>, etc.).
+- For any state space, different [state samplers](samplers.html) can be used (e.g., uniform, Gaussian, obstacle based, etc.).
 - [API overview](api_overview.html)
 
 \htmlonly</div><div class="span4">\endhtmlonly

doc/dox/releaseNotes.md

 - Added the notion of objectives to be optimized: ompl::base::OptimizationObjective
 - Added \ref gTRRT "T-RRT", a planner for planning low-cost paths.
 - Planners now have the option to report the non-existence of a solution (ompl::base::SolutionNonExistenceProof)
+- Improved infrastructure for creating python bindings for planners (see [tutorial](pybindingsPlanner.html) for details)
 - Documentation updates.
 - Bug fixes.
 

doc/dox/tutorials.md

 - [Geometric planning for a rigid body in 3D](geometricPlanningSE3.html)
 - [Setting up state validity checking](stateValidation.html)
 - [Working with states and state spaces](workingWithStates.html)
-- [Using existing samplers and creating new ones](availableSamplers.html)
+- [Using existing samplers and creating new ones](samplers.html)
 
 
 ### Intermediate
               <li><a href="tutorials.html">Tutorials</a></li>
               <li><a href="group__demos.html">Demos</a></li>
               <li><a href="python.html">Python Bindings</a></li>
-              <li><a href="availablePlanners.html">Available Planners</a></li>
-              <li><a href="availableStateSpaces.html">Available State Spaces</a></li>
+              <li><a href="planners.html">Available Planners</a></li>
+              <li><a href="spaces.html">Available State Spaces</a></li>
               <li><a href="FAQ.html">FAQ</a></li>
               <li class="divider">
               <li>&nbsp;<em>External links:</em></li>