Note: This tutorial assumes that you have completed the previous tutorials: Converting Arm Navigation trajectory filters into MoveIt Planning Request Adapters.
(!) Please ask about problems and questions regarding this tutorial on answers.ros.org. Don't forget to include in your question the link to this page, the versions of your OS & ROS, and also add appropriate tags.

Using a planning adapter inside of MoveIt.

Description: This tutorial will show you how to use a planning request adapter with MoveIt.

Keywords: Trajectory Filter MoveIt Arm Planning

Tutorial Level: ADVANCED

This tutorial will teach you how to use an industrial trajectory filter that was converted into a planning adapter inside of MoveIt.

Planning Request Adapter - General Use

In order to use your new Planning Request Adapter inside a MoveIt generated package do the following:

  1. Open the ompl_planning_pipeline.launch file of the MoveIt package for your robot and add your filter to the beginning of the planning_adapters list as follows:

       1 <arg name="planning_adapters" value="
       2     my_filter_package/MyFilter
       3     default_planner_request_adapters/AddTimeParameterization
       4     default_planner_request_adapters/FixWorkspaceBounds
       5     default_planner_request_adapters/FixStartStateBounds
       6     default_planner_request_adapters/FixStartStateCollision
       7     default_planner_request_adapters/FixStartStatePathConstraints" />
    
  2. In the same launch file, declare any ros parameters used by your filter as shown below:
       1 <param name="my_filter_parameter" value="40" />
    
  3. At this point you can now use the filter. Run demo.launch from your MoveIt generated package and create path plans using the MovePlanningPlugin in RViz. If your filter prints to stdout, then you should see the output from it right after you generate a path.

Example

The following section illustrates a specific example of using the uniform sample filter from the industrial_trajectory_filters package.

  1. Following the steps above ompl_planning_pipeline.launch file should be modified to match the following (original taken from motoman_sia20d_moveit_config package):

       1 <launch>
       2 
       3   <!-- OMPL Plugin for MoveIt! -->
       4   <arg name="planning_plugin" value="ompl_interface/OMPLPlanner" />
       5 
       6   <!-- The request adapters (plugins) used when planning with OMPL. 
       7        ORDER MATTERS -->
       8   <arg name="planning_adapters" value="industrial_trajectory_filters/UniformSampleFilter
       9 default_planner_request_adapters/AddTimeParameterization
      10                                        default_planner_request_adapters/FixWorkspaceBounds
      11                                        default_planner_request_adapters/FixStartStateBounds
      12                                        default_planner_request_adapters/FixStartStateCollision
      13                                        default_planner_request_adapters/FixStartStatePathConstraints" />
      14 
      15   <arg name="start_state_max_bounds_error" value="0.1" />
      16 
      17   <param name="planning_plugin" value="$(arg planning_plugin)" />
      18   <param name="request_adapters" value="$(arg planning_adapters)" />
      19   <param name="start_state_max_bounds_error" value="$(arg start_state_max_bounds_error)" />
      20   <param name="sample_duration" value="0.2"/>
      21 
      22   <rosparam command="load" file="$(find motoman_sia20d_moveit_config)/config/ompl_planning.yaml"/>
      23 
      24 </launch>
    

Two modifications were made to the file:

  • Added industrial_trajectory_filters/UniformSampleFilter to the planning_adapters list parameter. By adding this filter to the beginning of the list, we ensure that it is the last filter to be applied. This happens because the list is used for pre-processing trajectories (before planning), in which case the list is executed in order, and post-processing (after planning), in which case the list is executed in reverse order.

  • Added <param name="sample_duration" value="0.2"/> as a filter parameter. The parameter name is specific to each filter (documented here), in this case sample_duration controls the desired time between waypoints after the filter is applied.

Wiki: industrial_trajectory_filters/Tutorials/filters_inside_moveit (last edited 2015-12-07 16:44:48 by ShaunEdwards)