On Mon, 9 Apr 2012, Stephen Roderick wrote:

> On Apr 9, 2012, at 08:39 , Herman Bruyninckx wrote:
>
>> On Mon, 9 Apr 2012, Stephen Roderick wrote:
>>
>>>
>>> On Apr 9, 2012, at 08:16 , Ruben Smits wrote:
>>>
>>>> On Mon, Apr 9, 2012 at 2:15 PM, Ruben Smits
>>>> <ruben [dot] smits [..] ...> wrote:
>>>>> On Mon, Apr 9, 2012 at 1:55 PM, Stephen Roderick <kiwi [dot] net [..] ...> wrote:
>>>>>> On Apr 9, 2012, at 07:49 , Herman Bruyninckx wrote:
>>>>>>
>>>>>>> On Mon, 9 Apr 2012, S Roderick wrote:
>>>>>>>
>>>>>>>> There is no support in KDL (v1) for changing a chain, once created,
>>>>>>>> particularly changing the final segment's frame to support tool
>>>>>>>> modifications/changes. It looks like the chain and each of the solver
>>>>>>>> classes would all require the ability to update the frame within a
>>>>>>>> segment of a chain. More extensive than I was hoping for.
>>>>>>>>
>>>>>>>> How have others solved this? Are you just taking the potential real-time
>>>>>>>> hit and reallocating new chains and solvers? Or do you simply not have
>>>>>>>> changeable tools installed?
>>>>>>>
>>>>>>> Most often, new tools introduce constant changes between the "Tool Centre
>>>>>>> Point" frame and the chain's "End effector" frame, and these constant
>>>>>>> transformations are easily provided by the application that uses the chain.
>>>>>>
>>>>>> What I don't see in your answer is how you do inverse kinematics to move about an arbitrary tool pose w.r.t. the end of the robot, _AND_ you want to be able to modify this tool pose sometimes. How do you include the changeable tool pose in your IK as part of KDL?
>>>>>>
>>>>>
>>>>> In the case of inverse position kinematics you can easily 'substract'
>>>>> the tool pose from the desired pose before sending it to the IK
>>>>> algorithm:
>>>>>
>>>>> T_ee_desired = T_tool_desired*T_ee_to_tool.Inverse()
>>>>>
>>>>> In the case of inverse velocity kinematics you can easily change the
>>>>> reference point of the twist before sending it to the IK algorithm:
>>>>>
>>>>> t_ee_desired = t_ee_tool.RefPoint(-p_ee_tool)
>>>>
>>>> Correction:
>>>>
>>>> t_ee_desired = t_tool_desired.RefPoint(-p_ee_tool)
>>>
>>> Ok, that makes sense.
>>>
>>> BTW as a matter of interest, what do you guys define "end effector" as? Particularly vs "tool"?
>>
>> We use the (very old) ISO norm on robot terminology:
>>
>> - "end effector: is the mechanical part of the robot to which tools can be
>> attached.
>> - TCP: frame on a tool that is attached to a robot's end-effector, and for
>> which the transformation between EE frame and TCP is known.
>>
>> In summary: EE is always fixed to the robot (hence it is the normal one to
>> base the kinematics solvers on), while the TCP can change during the task.
>
> So what if you have several items between the physical end of the robot and the point at which tools are attached. Is the EE frame at the end of the robot, or at the actual point that a tool is attached?

Take the simple definition of a tool: it is _everything_ that is (rigidly)
connected to the robot's end-effector. The "number of items" that
mechanically make up the tool is not relevant. Unless there are
degrees-of-freedom in those mechanical interconnections; that changes the
matter drastically, of course, since those degrees of freedom add to the
"kinematic chain" you have to consider.

> S

Herman