Note: This tutorial assumes that you have completed the previous tutorials: Configuring a joint space planner. |
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. |
Launching a joint space planner
Description: Launching a joint space plannerTutorial Level: BEGINNER
Next Tutorial: Calling the joint space planner
You are now almost ready to start planning. A few additional parameters first have to be specified but you can choose to use the default parameters specified below (depending on the case that you are planning for).
Other Parameters (Required)
Additional parameters need to be specified to fully configure the planning environment, i.e. the representation of the robot and the environment that the planner will use.
Planning only with self-collisions
If you are planning only with self-collisions, i.e. you have no sensors on your robot that can give you a representation of the environment as a collision map or you just want to ignore such sensor information, here's a pre-configured set of parameters:
use_collision_map: false collision_map_safety_timeout: 10000.0 joint_states_safety_timeout: 1.0 tf_safety_timeout: 10.0 default_robot_padding: 0.02 link_padding: - link: right_arm padding: .02
The link padding is essentially a list of links for which you can specify a padding or clearance parameter. This is important since you want the robot to stay away from obstacles.
You should put this set of parameters in your example_planning.yaml file that you created in the previous tutorial.
Planning with self-collisions and a collision map
If you are planning with self-collisions and a collision map generated by your robot's sensors (e.g. a tilting laser scanner, a RGB-D sensor or a stereo camera, etc.), here's a pre-configured set of parameters:
use_collision_map: true default_robot_padding: 0.02 link_padding: - link: right_arm padding: .02
The link padding is essentially a list of links for which you can specify a padding or clearance parameter. This is important since you want the robot to stay away from obstacles.
You should put this set of parameters in your example_planning.yaml file that you created in the previous tutorial. Also make sure that you have a source that publishes a collision map on the collision_map topic. See the CollisionMap message description for more details on the format expected. You can also look at the collision_map package for more information on how collision maps are generated from the PR2 sensors.
Launching the planner
You need to include the configuration file you generated in the previous tutorial in a launch file. Here's an example launch file that you can use (save it as example_planning.launch in your example_planning package):
<launch> <node pkg="ompl_ros_interface" type="ompl_ros" name="ompl_planning" output="screen"> <rosparam command="load" file="$(find example_planning)/example_planning.yaml" /> </node> </launch>
Now, launch this file to get your planner up and running.
roslaunch example_planning example_planning.launch
More details (Optional)
This section is for more advanced users that would like to play around with the configuration a little more. Listed here are the minimal set of parameters that you need to be aware of and configure for more advanced behaviors.
~robot_description (string, default: "robot_description")
- The name of the ROS parameter that contains the string representation of the URDF for the robot.
- If true and allowable contact regions exist, collisions inside the allowed contact regions will be ignored.
- If > 0.0 seconds, the node will expect the collision map to be published regularly within this interval of time. If the node has not received a collision map within the interval it will declare all states and trajectories unsafe.
- If > 0.0 seconds, the node will expect the joint states to be published more frequently than this safety timeout. If the node has not received joint states within the interval it will declare all states and trajectories unsafe.
- If the global frame is specified to be the empty string, the root frame in which all monitoring will take place is the root link of the robot ("base_link" for the robot). Otherwise, this parameter can be set to a fixed frame in the world (e.g. "odom_combined", "map")
- The expected interval between TF updates. If global_frame is set to a valid fixed frame (and not to its default of an empty string), THEN if the node has not received TF updates within this interval it will declare all states and trajectories unsafe.
- If true, collision map information is expected and used in the collision space. If the robot has no sensors to create a representation of the environment or if you do not want to take 3D sensor data into account while planning, set this to false.
- The value for a padding to add around the collision bodies associated with all links in the collision space. Note that <robot_description_name> will be replaced with either robot_description or whatever value has been remapped for robot_description.