Rosanswers logo

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?

Originally posted by Martin Günther on ROS Answers with karma: 11816 on 2011-05-24

Post score: 5


1 Answer 1


Rosanswers logo

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: http://www.ros.org/wiki/arm_kinematics_constraint_aware/Tutorials

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.

Originally posted by Sachin Chitta with karma: 1304 on 2011-05-24

This answer was ACCEPTED on the original site

Post score: 10

Original comments

Comment by Sachin Chitta on 2011-06-07:
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.

Comment by Nash on 2011-06-05:
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?

Comment by Sachin Chitta on 2011-05-25:
Yes. Looking forward though - a plugin implementation would be more future-proof. It will let you use more advanced features in ompl_ros_interface.

Comment by Martin Günther on 2011-05-25:
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?

Comment by Martin Günther on 2011-05-24:
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?


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.