[ros-users] kinematics stack status ?

Tue Jan 18 22:24:31 UTC 2011

2011/1/18 Sachin Chitta <sachinc at willowgarage.com>

> 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.
>
But why that would need new message, putting string[] joint_names float64[]
joint_positions directly into the service would not be sufficient ?

> I will look into your kinematics_utils package.
>
I forgot to send you link to my repo :  https://github.com/konradb3/sandbox

>
> 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
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20110118/c7b002cd/attachment-0003.html>