[ros-users] kinematics stack status ?

[Sachin Chitta]

JointState is a frozen message currently. The option would be to use a
different message there that just contains position. This would create yet
another message and we want to keep the number of messages representing
basic quantities at a minimum. Having a couple of extra fields that will be
ignored is a small price to pay here. We can make it clear in the
documentation that these fields in the jointstate message are ignored by the
solvers.

I will look into your kinematics_utils package.

Sachin

On Tue, Jan 18, 2011 at 2:01 PM, Konrad Banachowicz <konradb3 at gmail.com>wrote:

> 2011/1/18 Sachin Chitta <sachinc at willowgarage.com>
>
>> 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 at gmail.com>wrote:
>>
>>> 2011/1/16 Herman Bruyninckx <Herman.Bruyninckx at 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 at code.ros.org
>>>> https://code.ros.org/mailman/listinfo/ros-users
>>>>
>>>>
>>>
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users at code.ros.org
>>> https://code.ros.org/mailman/listinfo/ros-users
>>>
>>>
>>
>>
>> --
>> Sachin Chitta
>> Research Scientist
>> Willow Garage
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>


-- 
Sachin Chitta
Research Scientist
Willow Garage
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20110118/a959305b/attachment-0003.html>