New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Planning Request Adapters tutorials #220

Merged
merged 17 commits into from Oct 13, 2018

Conversation

Projects
None yet
4 participants
@raghavendersahdev
Copy link
Contributor

raghavendersahdev commented Sep 3, 2018

Addition of tutorial for running Planning Request Adapters in MoveIt

This PR is work done by Raghavender as a part of 2018 Google summer of code. As a part of this PR, a page on Planning Request Adapters has been created which enables the user to use multiple motion planners in a pipeline to produce robust motion plans. Some planning insights on using different motion planners is also provided as a part of this PR. @davetcoleman @mamoll

Checklist

  • addition of tutorials for running Planning Adapters concept and allowing users to mix and match multiple motion planners
  • instructions for using CHOMP as a post-processor for OMPL
  • instructions for using CHOMP as a post-processor for STOMP
  • instructions for using STOMP as a post-processor for OMPL
  • instructions for using STOMP as a post-processor for CHOMP
  • STOMP smoothing adapter is currently under development and a separate PR in ros-planning/moveit repo will be made soon in a few dats for enabling the required STOMP adapter behavior

@raghavendersahdev raghavendersahdev changed the title Planning adapters tutorials Planning Request Adapters tutorials Sep 3, 2018

@mamoll

This comment has been minimized.

Copy link

mamoll commented Sep 5, 2018

Looks good to me. 👍


- *trajectory_initializaiton_method*: the type of initialization of the trajectory can be supplied here for CHOMP, this can be ``quintic-spline``, ``linear``, ``cubic`` or ``fillTrajectory``. The first three options refer to the interpolation methods used for trajectory initialization between start and goal states. ``fillTrajectory`` provides an option of initializing the trajectory from path computed from an existing motion planner like OMPL.

Choosing parameters for CHOMP requires some sort of intuition based on the environment we are working in. One can have the default parameters for CHOMP and this works well in environments without obstacles. However in cases where the scene is populated with obstacles, we need to vary some parameters to ensure that CHOMP is not stuck in local minima, or quickly finds optimal solutions, preferring trajectories which avoids obstacles. Some parameters like increasing the *ridge_factor* to say 0.001 makes CHOMP avoids obstacles by not preferring smooth trajectories, so there is a trade-off between smoothness and CHOMP's ability to avoid obstacles. Choosing the correct number of *max_iterations*, *learning_rate* is important based on the environment we are working in. Not choosing the appropriate CHOMP parameters might lead to CHOMP reporting not finding a collision-free path. *collision_clearance*, *collision_threshold* parameters are useful in specifying the minimum distance to be kept from obstacles to avoid collisions.

This comment has been minimized.

@mlautman

mlautman Sep 5, 2018

Member

Trim to:

Choosing parameters for CHOMP requires some intuition that is informed by the planning environment. For instance, the default parameters for CHOMP work well in environments without obstacles; however, in environments with many obstacles the default parameters will likely cause CHOMP to get stuck in local minima. By tweaking parameters, we can improve the quality of plans generated by CHOMP.

The rest is redundant.

This comment has been minimized.

@raghavendersahdev

Some of the unused/commented parameters are *hmc_stochasticity*, *hmc_annealing_factor*, *hmc_discretization*, *use_hamiltonian_montecarlo*, *animate_endeffector*, *animate_endeffector_segment*, *animate_path*, *random_jump_amount*, *add_randomness*.

Difference between plans obtained by CHOMP and OMPL
---------------------------------------------------
Optimizing planners optimize a cost function that may sometimes lead to surprising results: moving through a thin obstacle might be lower cost than a long, winding trajectory that avoids all collisions. In this section we make a distinction between paths obtained from CHOMP and contrast it to those obtained from OMPL.

OMPL is a open source library for sampling based / randomized motion planning algorithms. Sampling based algorithms are probabilistically complete: a solution would be eventually found if one exists, however non-existence of a solution cannot be reported. These algorithms are efficient and usually find a solution quickly. OMPL does not contain any code related to collision checking or visualization as the designers of OMPL did not want to tie it to a any particular colision checker or visualization front end. The library is designed so it can be easily integrated into systems that provide the additional components. MoveIt integrates directly with OMPL and uses the motion planners from OMP as its default set of planners. The planners in OMPL are abstract; i.e. OMPL has no concept of a robot. Instead, MoveIt! configures OMPL and provides the back-end for OMPL to work with problems in Robotics.
OMPL is a open source library for sampling based / randomized motion planning algorithms. Sampling based algorithms are probabilistically complete: a solution would be eventually found if one exists, however non-existence of a solution cannot be reported. These algorithms are efficient and usually find a solution quickly. OMPL does not contain any code related to collision checking or visualization as the designers of OMPL did not want to tie it to a any particular collision checker or visualization front end. The library is designed so it can be easily integrated into systems that provide the additional components. MoveIt integrates directly with OMPL and uses the motion planners from OMPL as its default set of planners. The planners in OMPL are abstract; i.e. OMPL has no concept of a robot. Instead, MoveIt! configures OMPL and provides the back-end for OMPL to work with problems in Robotics.

This comment has been minimized.

@mlautman

mlautman Sep 5, 2018

Member

Change all MoveIt -> MoveIt!

This comment has been minimized.

@raghavendersahdev

CHOMP: While most high-dimensional motion planners separate trajectory generation into distinct planning and optimization stages, CHOMP capitalizes on covariant gradient and functional gradient approaches to the optimization stage to design a motion planning algorithm based entirely on trajectory optimization. Given an infeasible naive trajectory, CHOMP reacts to the surrounding environment to quickly pull the trajectory out of collision while simultaneously optimizing dynamical quantities such as joint velocities and accelerations. It rapidly converges to a smooth collision-free trajectory that can be executed efficiently on the robot. A covariant update rule ensures that CHOMP quickly converges to a locally optimal trajectory.

For scenes containing obstacles, CHOMP often generates paths which do not prefer smooth trajectories by addition of some noise (*ridge_factor*) in the cost function for the dynamical quantities of the robot (like acceleration, velocity). CHOMP is able to avoid obstacle in most cases but it can fail if it gets stuck in the local minima due to a bad initial guess for the trajectory. OMPL can be used to generate collision-free seed trajectories for CHOMP to mitigate this issue.

This comment has been minimized.

@mlautman

mlautman Sep 5, 2018

Member

obstacle -> obstacles

This comment has been minimized.

@raghavendersahdev
default_planner_request_adapters/FixStartStatePathConstraints
default_planner_request_adapters/CHOMPOptimizerAdapter" />

#. The values of the ``planning_adapters`` is the order in which the mentioned adapters are called / invoked. Order here matters. Inside the CHOMP adapter, a `call <https://github.com/ros-planning/moveit/tree/kinetic-devel/moveit_ros/planning/planning_request_adapter_plugins/src/chomp_optimizer_adapter.cpp#L174>`_ to OMPL is made before invoking the CHOMP optimization solver, so CHOMP takes the initial path computed by OMPL as the starting point to further optimize it.

This comment has been minimized.

@mlautman

mlautman Sep 5, 2018

Member

The values of the -> The order of the

This comment has been minimized.

@raghavendersahdev
default_planner_request_adapters/FixStartStatePathConstraints
default_planner_request_adapters/CHOMPOptimizerAdapter" />

#. The values of the ``planning_adapters`` is the order in which the mentioned adapters are called / invoked. Order here matters. Inside the CHOMP adapter, a `call <https://github.com/ros-planning/moveit/tree/kinetic-devel/moveit_ros/planning/planning_request_adapter_plugins/src/chomp_optimizer_adapter.cpp#L174>`_ to OMPL is made before invoking the CHOMP optimization solver, so CHOMP takes the initial path computed by OMPL as the starting point to further optimize it.

This comment has been minimized.

@mlautman

mlautman Sep 5, 2018

Member

Remove "Order here matters." It is redundant

This comment has been minimized.

@raghavendersahdev
default_planner_request_adapters/FixStartStatePathConstraints
default_planner_request_adapters/CHOMPOptimizerAdapter" />

#. The values of the ``planning_adapters`` is the order in which the mentioned adapters are called / invoked. Order here matters. Inside the CHOMP adapter, a `call <https://github.com/ros-planning/moveit/tree/kinetic-devel/moveit_ros/planning/planning_request_adapter_plugins/src/chomp_optimizer_adapter.cpp#L174>`_ to OMPL is made before invoking the CHOMP optimization solver, so CHOMP takes the initial path computed by OMPL as the starting point to further optimize it.

This comment has been minimized.

@mlautman

mlautman Sep 5, 2018

Member

For the URL it is better to use variable substitution available in the conf.py so that it automatically updates when we switch from kinetic to melodic. I don't feel strongly that this should be changed here. Just a heads up that using the conf.py is a really good option.

This comment has been minimized.

@raghavendersahdev

raghavendersahdev Sep 11, 2018

Contributor

done added this in my latest commit

Running OMPL as a pre-processor for STOMP
+++++++++++++++++++++++++++++++++++++++++

NOTE: Currently the development for STOMP Smoothing Adapter is work in progress.

This comment has been minimized.

@mlautman

mlautman Sep 5, 2018

Member

NOTE: The STOMP Smoothing Adapter is a work in progress.

Running STOMP as a post-processor for CHOMP
+++++++++++++++++++++++++++++++++++++++++++

NOTE: Currently the development for STOMP Smoothing Adapter is work in progress.

This comment has been minimized.

@mlautman

mlautman Sep 5, 2018

Member

same as above

This comment has been minimized.

@raghavendersahdev
@davetcoleman

This comment has been minimized.

Copy link
Member

davetcoleman commented Sep 6, 2018

Build failed for understandable reasons (missing files in current website)

@davetcoleman

This comment has been minimized.

Copy link
Member

davetcoleman commented Sep 11, 2018

ping @raghavendersahdev, @mlautman left some good feedback here

@davetcoleman

This comment has been minimized.

Copy link
Member

davetcoleman commented Sep 27, 2018

Travis fails because ros-planning/moveit#1012 is not merged in yet

@raghavendersahdev

This comment has been minimized.

Copy link
Contributor

raghavendersahdev commented Oct 1, 2018

ros-planning/moveit#1012 ready to be merged in

@davetcoleman

This comment has been minimized.

Copy link
Member

davetcoleman commented Oct 13, 2018

Restarted build after merge. It will probably still fail, but less.

@davetcoleman davetcoleman merged commit d22c2aa into ros-planning:kinetic-devel Oct 13, 2018

1 check failed

continuous-integration/travis-ci/pr The Travis CI build failed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment