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.

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 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.

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.

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