On Thu, 24 Jul 2008, Ruben Smits wrote:

> On Thursday 24 July 2008 11:33:59 threelight wrote:
>>> especially I'm interested in the KDL::Twist-input parameter of
>>> KDL::ChainIkSolverVel_pinv::CartToJnt (const JntArray &q_in, const Twist
>>> &v_in, JntArray &qdot_out)
>>>
>>> Ah, this is the tricky part, it is the velocity of the end-effector-frame
>>> with expressed int the base-frame of the chain (right before the first
>>> joint) but with it's reference point at the end-effector(to make sure
>>> that rotations are around the endeffector point)
>>
>> ok, but is the reference point at the end-effector equal to the third frame
>> according to this message:
>>
>> "A Twist does not have an absolutely fixed reference frame: you use it to
>> represent the velocity of one frame with respect to another frame,
>> expressed with respect to still another THIRD frame"
>
> No it is the velocity with it's reference frame the base, it's reference point
> the endeffector, from the endeffector to the THIRD frame
Ruben, I do not really understand your 'explanation' above... :-)
Basically, you have to give the following information in order to be
(fully?) unambiguous
- your twist gives the velocity of what frame with respect to what other
frame? (This is, in principle, a coordinate-independent piece of
information.)
- in what (possible third) frame are the _coordinates_ of this velocity
expressed?
- if you use a Twist to represent this velocity, you have to give the
meaning of all six elements in its coordinate representation:
- which three of the six numbers represent translational velocity?
- which three of the six numbers represent rotational velocity?
- what units do you use to represent velocities (radians/sec, mm/sec,
km/hrs, rpm, ...)

As you can see, making the interpretation of a rigid body velocity
totally unambiguous is hard... Hiding the ambiguity (as is done in most
other libraries) is however not a good option in my opinion, so we should
cope with this complexity explicitly... Hence, the need for a "semantic
API", which gives the coordinate-independent, physical meaning, _and_ which
has "inspection methods" to found out what coordinate and unit choices have
been made in a particular Twist implementation...

> [...]
>> Another question would be:
>>
>> Can I put the output-Twist of KDL::Path_Line:: Twist Vel (double s, double
>> sd) directly into the input-Twist-Parameter of
>> KDL::ChainIkSolverVel_pinv::CartToJnt (const JntArray &q_in, const Twist
>> &v_in, JntArray &qdot_out) or is ist necessary to transform first?
>
> You probably have to transform it in such a way that the the Twist is
> expressed in the robot's base frame (I think the output of Path_Line is a
> twist with reference frame and reference point on the path point)

Herman

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm