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

added tutorial section to use OMPL as a pre-processor for CHOMP #204

Closed
wants to merge 9 commits into
base: kinetic-devel
from

Conversation

Projects
None yet
3 participants
@raghavendersahdev
Copy link
Contributor

raghavendersahdev commented Aug 2, 2018

Addition of tutorial for running OMPL as a pre-processor planner for CHOMP

This PR is a work done by Raghavender as a part of 2018 Google summer of code. As a part of this PR, CHOMP planning adapter can be used to optimize paths obtained from OMPL.

Checklist

  • addition of tutorials for running OMPL to produce an initial guess for CHOMP
  • corresponding PR for the relevant code is available here PR#1012
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 also fails in some if it gets stuck in the local minima and might report a solution not found due to a naive initial guess for the trajectory. OMPL on the other hand generates collision free smooth paths in the presence of obstacles too.

This comment has been minimized.

@mlautman

mlautman Aug 2, 2018

Member

The wording is off and overly verbose. You should change it to the following:

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.

@raghavendersahdev

raghavendersahdev Aug 2, 2018

Contributor

done, thanks Mike.

Using OMPL as a pre-processor for CHOMP
---------------------------------------
Here, it is demonstrated that CHOMP can also be used as a post processing optimization technique for plans obtained by other planners like OMPL. This section has the instructions for performing this behaviour. The intuition behind this is that OMPL acts as the initial planner to produce an initial guess for CHOMP. CHOMP then takes this initial guess and further optimizes the trajectory. This somewhat gaurantees optimized trajectories.

This comment has been minimized.

@mlautman

mlautman Aug 2, 2018

Member

Change: "planners like OMPL" to "planning algorithms"
Remove: "This section has the instructions for performing this behaviour."
Change "OMPL acts as the initial planner" -> Some randomized planning algorithm.
Remove: "This somewhat gaurantees optimized trajectories". This statement is meaningless.

This comment has been minimized.

@raghavendersahdev
default_planner_request_adapters/FixStartStateCollision
default_planner_request_adapters/FixStartStatePathConstraints

This comment has been minimized.

@mlautman

mlautman Aug 2, 2018

Member

remove empty line unless it is necessary.

This comment has been minimized.

@raghavendersahdev
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/raghavendersahdev/moveit/blob/CHOMP_planning_request_adapter/moveit_ros/planning/planning_request_adapter_plugins/src/chomp_optimizer_adapter.cpp#L183>`_ to OMPL is made before invoking the CHOMP optimization sover, so CHOMP takes the initial path computed by OMPL as the starting point to further optimize it.

This comment has been minimized.

@mlautman

mlautman Aug 2, 2018

Member

planning_adapters

Also this link should point to upstream not your fork.

This comment has been minimized.

@raghavendersahdev
#. 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/raghavendersahdev/moveit/blob/CHOMP_planning_request_adapter/moveit_ros/planning/planning_request_adapter_plugins/src/chomp_optimizer_adapter.cpp#L183>`_ to OMPL is made before invoking the CHOMP optimization sover, so CHOMP takes the initial path computed by OMPL as the starting point to further optimize it.

#. Find the line where ``<rosparam command="load" file="$(find panda_moveit_config)/config/ompl_planning.yaml"/>`` is mentioned and replace it with: ::

This comment has been minimized.

@mlautman

mlautman Aug 2, 2018

Member

No need to replace this line. Simply tell the reader to add the chomp_planning.yaml line after the ompl_planning.yaml line

This comment has been minimized.

@raghavendersahdev

raghavendersahdev Aug 2, 2018

Contributor

done, yes thats better, thanks

#. Find the line where ``<rosparam command="load" file="$(find panda_moveit_config)/config/ompl_planning.yaml"/>`` is mentioned and replace it with: ::

<rosparam command="load" file="$(find panda_moveit_config)/config/ompl_planning.yaml"/>

This comment has been minimized.

@mlautman

mlautman Aug 2, 2018

Member

remove and change instructions to tell the user to add the chomp line not replace the ompl_planning line

This comment has been minimized.

@raghavendersahdev
<rosparam command="load" file="$(find panda_moveit_config)/config/chomp_planning.yaml"/>

#. Doing these additions basically adds a CHOMP Optimization adapter and loads up the corresponding CHOMP planner's parameters, if not included default CHOMP parameter values would be used for the CHOMP Optimization adapter. To do this with your own robot replace ``panda_moveit_config`` to ``robot_moveit_config`` of your robot.

This comment has been minimized.

@mlautman

mlautman Aug 2, 2018

Member

Replace this paragraph with:
These additions will add a CHOMP Optimization adapter and load the corresponding CHOMP planner's parameters. To do this with your own robot replace ``panda_moveit_config`` to ``<my_robot>_moveit_config`` of your robot.

This comment has been minimized.

@raghavendersahdev
#. Doing these additions basically adds a CHOMP Optimization adapter and loads up the corresponding CHOMP planner's parameters, if not included default CHOMP parameter values would be used for the CHOMP Optimization adapter. To do this with your own robot replace ``panda_moveit_config`` to ``robot_moveit_config`` of your robot.

#. Also ensure that in the ``move_group.launch`` file of ``<robot_moveit_config>/launch`` folder for your robot, the defaut planner is ``ompl``. If not change it to ``ompl``.

This comment has been minimized.

@mlautman

mlautman Aug 2, 2018

Member

#. In the ``move_group.launch`` file of <my_robot>_moveit_config/launch folder for your robot, make sure that the default planner is ``ompl``.

This comment has been minimized.

@raghavendersahdev
#. Doing these additions basically adds a CHOMP Optimization adapter and loads up the corresponding CHOMP planner's parameters, if not included default CHOMP parameter values would be used for the CHOMP Optimization adapter. To do this with your own robot replace ``panda_moveit_config`` to ``robot_moveit_config`` of your robot.

#. Also ensure that in the ``move_group.launch`` file of ``<robot_moveit_config>/launch`` folder for your robot, the defaut planner is ``ompl``. If not change it to ``ompl``.

This comment has been minimized.

@mlautman

mlautman Aug 2, 2018

Member

Also, "default" is spelled incorrectly. Please use spell check on the entire tutorial to catch errors like this before opening a PR

This comment has been minimized.

@raghavendersahdev

raghavendersahdev Aug 2, 2018

Contributor

done, thanks, sure I will keep this in mind.

@davetcoleman

This comment has been minimized.

Copy link
Member

davetcoleman commented Aug 3, 2018

@mlautman @raghavendersahdev can someone look into why travis is failing? i realize its unrelated to this PR

@mlautman

This comment has been minimized.

Copy link
Member

mlautman commented Aug 3, 2018

@davetcoleman

This comment has been minimized.

Copy link
Member

davetcoleman commented Aug 4, 2018

please resolve merge conflict

@raghavendersahdev

This comment has been minimized.

Copy link
Contributor

raghavendersahdev commented Aug 4, 2018

resolved.

@raghavendersahdev

This comment has been minimized.

Copy link
Contributor

raghavendersahdev commented Aug 4, 2018

currently Travis is failing because I am linking this line here which does not exist right on the ros-planning/moveit kinetic branch, but after the merge of this PR #1012, it should be fine.

---------------------------------------
Here, it is demonstrated that CHOMP can also be used as a post-processing optimization technique for plans obtained by other planning algorithms. The intuition behind this is that some randomized planning algorithm produces an initial guess for CHOMP. CHOMP then takes this initial guess and further optimizes the trajectory.
To achieve this, follow the steps.

This comment has been minimized.

@davetcoleman

davetcoleman Aug 5, 2018

Member

use : at end of sentence

This comment has been minimized.

@raghavendersahdev
To achieve this, follow the steps.

#. Open the ``ompl_planning_pipeline.launch`` file in the ``<robot_moveit_config>/launch`` folder of your robot. For the panda robot it is `this <https://github.com/ros-planning/panda_moveit_config/blob/master/launch/ompl_planning_pipeline.launch.xml>`_ file. Edit this launch file, find the lines where ``<arg name="planning_adapters">`` is mentioned and change it to: ::

This comment has been minimized.

@davetcoleman

This comment has been minimized.

@raghavendersahdev
@mlautman
Copy link
Member

mlautman left a comment

+1 after making requested changes.


- *use_stochastic_descent*: set this to true/false if you want to use stochastic descent while optimizing the cost. In stochastic descent, a random point from the trajectory is used, rather than all the trajectory points. This is faster and guaranteed to converge, but it may take more iterations in the worst case.

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, prefering trajectories which ovoids obstacles. Some parameters like increasing the *ridge_factor* to say 0.001 makes CHOMP avoids obstacles by not prefering 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.
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 Aug 6, 2018

Member

fix double space "without obstacles"

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 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.

This comment has been minimized.

@mlautman

mlautman Aug 6, 2018

Member

OMPL "from OMP as"

This comment has been minimized.

@raghavendersahdev

@raghavendersahdev raghavendersahdev force-pushed the raghavendersahdev:kinetic-devel branch from 475dd77 to c9282cc Aug 6, 2018

@raghavendersahdev raghavendersahdev force-pushed the raghavendersahdev:kinetic-devel branch from dc7bd29 to 922afaf Sep 1, 2018

@raghavendersahdev

This comment has been minimized.

Copy link
Contributor

raghavendersahdev commented Oct 14, 2018

Hi @davetcoleman , I just realized and closed this PR because after the merge of PR #220 this PR was rendered redundant as #220 already included this PR's changes in it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment