This package contains the ROS interface for the sbpl_arm_planner package.
How to Use It
This package is intended to be used as the planner's interface to the arm_navigation stack. If you already know how to make planning requests to move_arm, then you are almost ready to go.
To request motion plans of the sbpl_arm_planner instead of your current planner you need to:
- Launch the proper launch file for the arm you intend to use. The launch folder contains two launch files that you can choose from to use with the PR2:
In your MoveArmGoal request message to move_arm,there are two changes that must be made:
// don't run IK - send pose constraint as-is to the planner my_msg.disable_ik = true; // sbpl planner service name my_msg.planner_service_name = std::string("sbpl_planning/plan_path");
If you don't already know how to send planning requests to move_arm, I suggest you check out the useful arm navigation tutorials.
- A 3D occupancy grid of the surrounding environment
- Objects in the environment that are known. They get added to the collision map.
- Objects that were added to the robot model - usually objects that the robot grasped. They get added to the robot's collision model.
- The goal pose and if enabled, the pose(position and orientation) of each node in the graph expanded during the search.
- The position of each node in the graph expanded during the search. If enabled, the path suggested by the heuristic function from the start position to the goal can be displayed.
- This service accepts planning requests and returns trajectories. Note: In its current form the planner will only attempt to plan a path for a goal position constraint. Direct requests to the planner with pose constraints will be handled correctly but pose constraint requests to move_arm need to have the 'disable_ik' flag set to true to be forwarded to the planner service correctly.
~/planner/search_mode (bool, default: true)
- Return first solution found.
- The initial epsilon to be used by the planner. Epsilon is the bounds on the suboptimality of the solution.
- If true, a lot of descriptive information is printed out before the search that describes the arm configuration, motion primitives, planner settings. A tolerable amount of data is printed out during the search.
- For the heuristic function, use the 3D distance to the goal calculated by Dijkstra's algorithm. If set to false, the Euclidean distance is used.
- For the heuristic function, use the 3D distance from the elbow position to any of the possible elbow poses when the end effector is at the goal pose.
- If true, it doesn't include a "distance to the nearest obstacle" cost in the cost function. If false, it tries to stay away from obstacles (may take longer to plan).
- If true, use one set of primitives when at least n meters from the goal, and a different set (usually with smaller motions) when closer to the goal. If false, use the same for the entire search.
- Path to the arm description text file.
- Path to the motion primitive text file.
~/planner/research/solve_with_ik_threshold (double, default: 0.10)
- The distance (meters) from the goal to start trying to solve for the goal pose using IK. Note: IK is pretty fast to compute but checking for collisions along the interpolated path to the goal from the current node's configuration takes time and so IK should not be called too far from the goal in a cluttered environment.
- If true, sum the end effector heuristic and elbow heuristic. If false, then take the maximum between the two.
- The distance in meters from the goal pose, when the search should switch to the short distance motion primitives.
~/debug/print_out_path (bool, default: true)
- Print the path to the terminal.
~robot_description (string, default: robot_description)
- The name of the ROS parameter that contains the URDF robot description of the robot.
- The number of joints that are being planned for.
- The name of the collision link group in the URDF that will be used for kinematic calculations and collision checking.
- The name of the reference frame used during planning. Note: At the moment, the collision map must be received in this frame as well.
- The name of the forward kinematics service.
- The name of the inverse kinematics service.
~/collision_space/reference_frame (string, default: base_link)
- The reference frame used for the collision map.
- The resolution of the occupancy grid.
- The topic of type mapping_msgs/CollisionMap, that the collision_map is being published on.
- x-coordinate of the origin of occupancy grid (cell 0,0,0) in meters.
- y-coordinate of the origin of occupancy grid (cell 0,0,0) in meters.
- z-coordinate of the origin of occupancy grid (cell 0,0,0) in meters.
- size in meters of the occupancy grid in the x dimension.
- size in meters of the occupancy grid in the y dimension.
- size in meters of the occupancy grid in the z dimension.
~/visualizations/heuristic (bool, default: false)
- Visualize the suggested 3D path from the start position to the goal pose in rviz.
- Visualize the goal pose as a sphere with an arrow.
- Visualize the poses of the states expanded during the search in rviz.
- Visualize the found trajectory (straight from the planner).
- Throttle the number of waypoints visualized (1: don't throttle).
- Visualize the spherical collision model of the arm along the trajectory.
- ROS API is UNREVIEWED and UNSTABLE
- C++ API is UNREVIEWED and UNSTABLE
- This planner has been developed for the PR2 only. Some changes would have to be made to make it work for another robot.
- This planner cannot currently deal with path constraints.
- This planner cannot currently deal with goal joint constraints (our main focus is in planning to goal pose constraints and letting the cost function decide on the goal arm configuration).
- This planner cannot deal with goal region constraints besides a cube.
- Until the grasping pipeline can handle pose constraints without using IK - this planner cannot be used with the grasping pipeline.
The planner keeps failing what is going wrong?
The planner tries to come up with the best possible solution within the allotted planning time. You should try raising the "allowed_planning_time" field in the MoveArmGoal message.
my_msg.motion_plan_request.allowed_planning_time = ros::Duration(5.0);
- The planner uses a cylindrical collision model of the arm. If your goal is set too close to an obstacle, the planner may not be able to find a solution that's collision free.
- The planner may be struggling to compute a path to the exact desired pose constraint that you set. Try increasing the tolerance on the position constraint to at least 1cm in all dimensions.