Ask Your Question

What ist the difference between the inverse kinematics service and the kinematics plugin?

asked 2011-05-24 01:23:34 -0600

updated 2011-05-24 22:26:05 -0600

Since Diamondback, it is possible to configure a planner with a kinematics plugin (see e.g. this tutorial). This allows to send cartesian pose goals to the planner. An alternative way to send cartesian pose goals is to provide a GetPositionIK service to move_arm.

My question is: What is the difference between these two approaches (service/plugin)? Are they completely interchangeable (in other words, do I need to provide only one of them)? Any advantages/disadvantages?

EDIT: I still don't quite get how all the parts (move_arm, ompl, kinematics plugin inside ompl, kinematics service) play together. For example, the kinematics plugin is configured in pr2_arm_navigation_planning/ompl_planning.yaml. At the same time, pr2_3dnav/right_arm_navigation.launch includes pr2_arm_navigation_kinematics/launch/right_arm_collision_free_ik.launch, which starts a (collision-free) IK service. So in which cases will the plugin be used, and in which cases the service?

edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted

answered 2011-05-24 17:59:01 -0600

Sachin Chitta gravatar image

updated 2011-05-25 04:49:58 -0600

You have three options for a new arm:

(1) Write a plugin for your arm: The plugin provides a direct C++ interface to any kinematics solver. If you implement the plugin for your arm, you can configure the generic kinematics node in the arm_kinematics_constraint_aware package to use this plugin. This saves you the trouble of configuring/writing your own constraint/collision aware kinematics package. This node advertises all the right services for use with move_arm.

(2) Provide a GetConstraintAwarePositionIK service for move_arm to use by writing your own node that duplicates the services provided by the arm_kinematics_constraint_aware node (and also by the pr2_arm_kinematics node).

(3) Use the arm kinematics node in the arm_kinematics_constraint_aware package configured with the KDL solvers for your arm. A tutorial for this is here:

Option (3) is the simplest but maybe not the most efficient solution. (1) is the way to go if you have a custom implementation of kinematics for your robot. It will also be the most efficient option. Option (2) will probably require the most work on your part.

This is an answer to Martin's follow up question/comment:

The way I envision this playing out in the future for anyone writing a custom kinematics solver for their arm:

(a) Write the custom kinematics implementation as a library

(b) Wrap it in a plugin - this allows you to (at runtime) configure (in YAML) components like the motion planners to use your kinematics implementation

(c) The generic kinematics node in arm_kinematics_constraint_aware can also use your plugin to expose the kinematics as ROS services. This is useful for things like move_arm which expect to communicate with everything over ROS.

Plugins allow easy runtime configuration using YAML - that is explicitly what they are meant for. They also give you a straight C++ interface which is more efficient (if you are going to call the kinematics thousands of times) than calling out over ROS services. This is important when a motion planner working in task space calls the inverse kinematics repeatedly. This is the way the pr2_kinematics is now configured for use with OMPL in ompl_ros_interface.

The ROS node exposes ROS functionality that is convenient for you to use and allows distribution of this functionality over multiple computers. In the future, the ROS node offering kinematics services for the PR2 will change over to using the plugin infrastructure. This is a change that will happen under the hood without affecting any users.

edit flag offensive delete link more


Thanks Sachin. The whole interplay of plugin/service is still not quite clear to me. I've updated my question, could you also respond to that?
Martin Günther gravatar image Martin Günther  ( 2011-05-24 22:21:27 -0600 )edit
Thanks again for your update. So, as long as i just use the normal joint space planners described in the OMPL tutorials, I only need to provide a normal constraint aware IK service to move_arm, and no plugin at all. Correct?
Martin Günther gravatar image Martin Günther  ( 2011-05-25 07:45:43 -0600 )edit
Yes. Looking forward though - a plugin implementation would be more future-proof. It will let you use more advanced features in ompl_ros_interface.
Sachin Chitta gravatar image Sachin Chitta  ( 2011-05-25 08:43:41 -0600 )edit
So when configuring the arm kinematics solvers on the PR2, is it possible to change to tip name of the right hand from "r_wrist_roll_link" to maybe "r_gripper_l_finger_tip_link" so that the "GetPositionIK" can get inverse kinematics solutions from the position kinematics solver?
Nash gravatar image Nash  ( 2011-06-05 00:38:37 -0600 )edit
With the current implementation of the pr2 kinematics, no. But the difference between those two frames is a transform that you can use externally to modify the input so that you specify the right input.
Sachin Chitta gravatar image Sachin Chitta  ( 2011-06-07 13:24:02 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2011-05-24 01:23:34 -0600

Seen: 1,312 times

Last updated: May 25 '11