Hi Konrad,

The GetKinematicSolverInfo was intended as a read-only information service that would provide information about the joint limits used in the solver. The service itself is a convenience service and not really essential since most of the information comes from the robot description. Note that none of the services impose any conditions on where the limits are sourced from. Currently, they are sourced from the robot description internally in the node but I could add an api where you can override those limits using ROS parameters.

ok so there should be corresponding for "plugins"

RobotState is intended for complete representation of a generic robot state and not just an arm. I am not sure what you mean by "contains alot of unnecessary data". Could you please clarify which fields are unnecessary.

I was thinking about multi_dof_joint_state field and vellocity and effort fields of joint_state. Those field seem to be ignored by kinematics solvers.

I expect the core kinematics services (GetPositionIK, GetPositionFK) themselves to be stable. The only possible change is to add a "group name" so you would not have to specify every joint to be used by the solver. The other possible change would be to add a new service that lets you call IK on a vector of poses to save the trouble of calling a service multiple times. I would prefer not to do a wholesale change of API but would like to get some of the convenience elements (like group names) in.

I do have an "plugin" implementation of the kinematics in place right now but I have not pushed it out. It lets you configure and call solvers using the plugin architecture used by other components in ROS (like the navigation stack). I will push it out for review in a few days after putting up more documentation.

Documentation would be very useful.

You are welcome to send more such feedback. In fact, if anyone would like to step up and volunteer to help maintain the kinematics stacks and do some of these API changes (like Jack O'Quinn is maintaining camera drivers), that would be more than welcome.

I have created kinematics_utils package containing useful functions from pr2_kinematics_utils and node capable of loading kinematics plugins and providing kinematics sevices.

Sachin

On Sun, Jan 16, 2011 at 11:09 AM, Konrad Banachowicz <konradb3@gmail.com> wrote:

2011/1/16 Herman Bruyninckx <Herman.Bruyninckx@mech.kuleuven.be>

On Sun, 16 Jan 2011, Konrad Banachowicz wrote:

I started to move our code for our robot kinematics to ROS.
I would like to know what is the stabilization status of kinematics stack,
because latst review happend nearly year ago.
I have some remarks and suggestions about kinematics stack :
- kinematics serwices use motion_planning_msgs/RobotState which contains alot of
unnecessary data.
- SolverInfo contains limits field which duplicate data avalible through
robot_description.

You might want to configure a solver with tighter limits than what the
robot's mechanics impose...
ok but those data are read-only by getSolverInfo service.
Currently every implementation simply send data readed from robot_description.

- pr2_kinematics contains many useful functions in pr2_arm_kinematics_utils.cpp
this could be moved to common package, maybe kinematics_utils.

- common node for ik and ik_with_constraints should exist, using kinematics
plugins.
This would simplify implementation of kinematics for new robot.

Herman
_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users

_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users

--
Sachin Chitta
Research Scientist
Willow Garage

_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users