Improve chomp_planner_tutorial text and formatting (#609)

Co-authored-by: Bey Hao Yun <cardboardmails@gmail.com>

Author: davetcoleman

doc/chomp_planner/chomp_planner_tutorial.rst

@@ -58,43 +58,70 @@ Tweaking some of the parameters for CHOMP
 -----------------------------------------
 CHOMP has some optimization parameters associated with it. These can be modified for the given environment/robot you are working with and is normally present in the :panda_codedir:`chomp_planning.yaml <config/chomp_planning.yaml>` file in config folder of the robot you are working with. If this file does not exist for your robot, you can create it and set the parameter values as you want. The following are some of the insights to set up these parameter values for some of them:
 
-- *planning_time_limit*: the maximum time the optimizer can take to find a solution before terminating
+- **planning_time_limit**: ::
+  The maximum time the optimizer can take to find a solution before terminating
 
-- *max_iterations*: this is the maximum number of iterations that the planner can take to find a good solution while optimization
+- **max_iterations**: ::
+  This is the maximum number of iterations that the planner can take to find a good solution while optimization
 
-- *max_iterations_after_collision_free*: maximum iterations to be performed after a collision-free path is found.
+- **max_iterations_after_collision_free**: ::
+  Maximum iterations to be performed after a collision-free path is found.
 
-- *smoothness_cost_weight*:  the smoothness_cost_weight parameters controls its weight in the final cost that CHOMP is actually optimizing over
+- **smoothness_cost_weight**:  ::
+  The smoothness_cost_weight parameters controls its weight in the final cost that CHOMP is actually optimizing over.
 
-- *obstacle_cost_weight*: this controls the weight to be given to obstacles towards the final cost CHOMP optimizes over. e.g., 0.0 would have obstacles to be ignored, 1.0 would be a hard constraint
+- **obstacle_cost_weight**: ::
+  This controls the weight to be given to obstacles towards the final cost CHOMP optimizes over. e.g., 0.0 would have obstacles to be ignored, 1.0 would be a hard constraint
 
-- *learning_rate*: this is the learning rate used by the optimizer to find the local / global minima while reducing the total cost.
+- **learning_rate**: ::
+  This is the learning rate used by the optimizer to find the local / global minima while reducing the total cost.
 
-- *smoothness_cost_velocity, smoothness_cost_acceleration, smoothness_cost_jerk*: variables associated with the cost in velocity, acceleration and jerk.
+- **smoothness_cost_velocity, smoothness_cost_acceleration, smoothness_cost_jerk**: ::
+  Variables associated with the cost in velocity, acceleration and jerk.
 
-- *ridge_factor*: the noise added to the diagonal of the total :moveit_codedir:`quadratic cost matrix<moveit_planners/chomp/chomp_motion_planner/src/chomp_cost.cpp#L62/>` in the objective function. Addition of small noise (e.g., 0.001) allows CHOMP to avoid obstacles at the cost of smoothness in trajectory.
+- **ridge_factor**: ::
+  The noise added to the diagonal of the total :moveit_codedir:`quadratic cost matrix<moveit_planners/chomp/chomp_motion_planner/src/chomp_cost.cpp#L62/>` in the objective function. Addition of small noise (e.g., 0.001) allows CHOMP to avoid obstacles at the cost of smoothness in trajectory.
 
-- *use_pseudo_inverse*: enable pseudo inverse calculations or not.
+- **use_pseudo_inverse**: ::
+  Enable pseudo inverse calculations or not.
 
-- *pseudo_inverse_ridge_factor*: set the ridge factor if pseudo inverse is enabled.
+- **pseudo_inverse_ridge_factor**: ::
+  Set the ridge factor if pseudo inverse is enabled.
 
-- *joint_update_limit*: set the update limit for the robot joints
+- **joint_update_limit**: ::
+  Set the update limit for the robot joints
 
-- *collision_clearance*: the minimum distance that needs to be maintained to avoid obstacles.
+- **collision_clearance**: ::
+  The minimum distance that needs to be maintained to avoid obstacles.
 
-- *collision_threshold*: the collision threshold cost that needs to be maintained to avoid collisions
+- **collision_threshold**: ::
+  The collision threshold cost that needs to be maintained to avoid collisions
 
-- *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.
+- **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.
 
-- *enable failure recovery*: if this is set to true, CHOMP tweaks ceratin parameters in the hope to find a solution when one does not exist with the default paramters specified in the ``chomp_planning.yaml`` file.
+- **enable failure recovery**: ::
+  If this is set to true, CHOMP tweaks ceratin parameters in the hope to find a solution when one does not exist with the default paramters specified in the ``chomp_planning.yaml`` file.
 
-- *max_recovery_attempts*: this is the maximum times that CHOMP is run with a varied set of parameters after the first attempt with the default parameters.
+- **max_recovery_attempts**: ::
+  This is the maximum times that CHOMP is run with a varied set of parameters after the first attempt with the default parameters.
 
-- *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.
+- **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 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.
 
-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*.
+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
 ---------------------------------------------------

doc/perception_pipeline/perception_pipeline_tutorial.rst

@@ -2,7 +2,7 @@ Perception Pipeline Tutorial
 ============================
 
 MoveIt allows for seamless integration of 3D sensors using `Octomap <http://octomap.github.io/>`_.
-Once properly configured, you should see something like this in rviz:
+Once properly configured, you should see something like this in RViz:
 
 .. image:: perception_configuration_demo.png
    :width: 700px
@@ -153,7 +153,7 @@ Detecting and Adding Object as Collision Object
 In this section, we will demonstrate an example of extracting a cylinder from a pointcloud, computing relevant values and adding it as a collision object to the planning scene.
 We will be working with point clouds but it can be implemented similarly with depth maps.
 
-After running the code, you should be able to see something like this in rviz:
+After running the code, you should be able to see something like this in RViz:
 
 .. image:: cylinder_collision_object.png
    :width: 700px