Skip to content
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

pick_ik failing consistently on IK when using setPoseTarget, while KDL easily solves #76

Open
mpollayil opened this issue Oct 16, 2024 · 0 comments

Comments

@mpollayil
Copy link

Hi all!

Thank you for this nice piece of solver. I was quite excited to see and official bio_ik kinematics solver plugin for MoveIt2!

I was testing out this plugin, but have encountered some issues. Let me give some context first:
I'm using the ROS2 Humble Docker image and using a ros2 node with MoveGroupInterface to plan motions. My robot has 6 DoF and the first joint is continuous. I installed pick_ik through the ros2 Humble binaries. This is one of my attempts for a kinematics.yaml:

manipulator:
  kinematics_solver: pick_ik/PickIkPlugin
  kinematics_solver_timeout: 1.0
  kinematics_solver_attempts: 5
  mode: local
  position_scale: 1.0
  rotation_scale: 0.8
  position_threshold: 0.01
  orientation_threshold: 0.1
  cost_threshold: 0.01
  minimal_displacement_weight: 0.01
  gd_step_size: 0.01
  approximate_solution_cost_threshold: 0.5

I encountered the following:

  • While planning to a joint value (using setJointValueTarget), everything works fine. This is reasonable since no IK should be performed to plan here.
  • When planning to a reasonable (in the reachable workspace of the robot) Cartesian pose using setPoseTarget, the planning always fails with the following:
[move_group-3] [INFO] [1729066005.990528959] [moveit_move_group_default_capabilities.move_action_capability]: Received request
[move_group-3] [INFO] [1729066005.990929340] [moveit_move_group_default_capabilities.move_action_capability]: executing..
[move_group-3] [INFO] [1729066005.994929103] [moveit_move_group_default_capabilities.move_action_capability]: Planning request received for MoveGroup action. Forwarding to planning pipeline.
[move_group-3] [INFO] [1729066005.996810194] [moveit.ompl_planning.model_based_planning_context]: Planner configuration 'manipulator' will use planner 'geometric::RRTConnect'. Additional configuration parameters will be set when the planner is constructed.
[move_group-3] [ERROR] [1729066011.002837195] [ompl]: ./src/ompl/geometric/planners/rrt/src/RRTConnect.cpp:252 - manipulator/manipulator: Unable to sample any valid states for goal tree
[move_group-3] [WARN] [1729066011.002906882] [moveit.ompl_planning.model_based_planning_context]: Timed out
[move_group-3] [INFO] [1729066012.019552019] [moveit.ompl_planning.model_based_planning_context]: Unable to solve the planning problem
[move_group-3] [INFO] [1729066012.019594309] [moveit_move_group_default_capabilities.move_action_capability]: Timeout reached
  • If I plan towards the same exact Cartesian pose using the default KDL solver with the same code (setPoseTarget), the plan is found in no time.
  • If I use computeCartesianPath toward the same Cartesian pose using pick_ik, the planning is 100% successful.

I assume there are no issues with my robot model since KDL is successful all the time. Is there anything wrong with my kinematics.yaml? Can there be any issues with the joint limits or continuous joints? I assume the problem is here with the inverse kinematics.

I would appreciate any hints or help. Thanks in advance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant