Help with 5 DOF arm

Hello all,

Quick question: I have a 5 dof arm I need to do inverse position
kinematics with (it doens't have a yaw joint). I've read through
messages in the mailing list about this but am still having some
trouble.

This conversation has been of help:
http://lists.mech.kuleuven.be/pipermail/orocos-users/2011-March/003255.html

But I'm not sure how to follow through. I have:

ChainFkSolverPos_recursive fksolver(chain);//Forward position solver
ChainIkSolverVel_wdls iksolver1v(chain);//Inverse velocity solver

Eigen::VectorXd weight_ts(6);
weight_ts[1]=weight_ts[2]=weight_ts[3]=weight_ts[3]=weight_ts[4]=1.0;//X,Y,Z,roll
pitch
weight_ts[5]=0.0;//yaw
iksolver1v.setWeightTS (weight_ts.asDiagonal());

ChainIkSolverPos_NR iksolver1(chain,fksolver,iksolver1v,1000,1e-3);
JntArray q(chain.getNrOfJoints());
JntArray q_init(chain.getNrOfJoints());

Frame F_dest=Frame(Rotation::RPY(-1.07, 0.94, 1.0), Vector(0.58,
-0.38, -0.85));
int ret = iksolver1.CartToJnt(q_init,F_dest,q);

If I plug in a frame that I know my robot can acheive (including the
yaw) the ik solver works, but if I just change the yaw value in F_dest
it will fail and return -3, which tells me its not ignoring the yaw.
Is there something else I need to do? Ruben mentions "adapt the
ChainFkSolverPos_recursive to also take a TaskSpace Weight into
account". Is this needed? Is it already implemented somewhere and I'm
missing it? If I need to do implement it myself, can someone point me
in the right direction?

thanks,
Aaron

Help with 5 DOF arm

It suddenly occurred to me that the solution to your problem
is easily solved with KDL, and I remembered your e-mail of 30 nov. 2012.
(it's a pity I did not think of it sooner, because it is a commonly used
method
to deal with e.g. contact situations).

The trick is to introduce a 6th _virtual_ joint. In this way an exact
solution
can be found. The solving of this new kinematic
chain can then be done with KDL. After solving, you just ignore the virtual
joint.

In this way, you will not need any task space weights.

Best regards,

Erwin.

On 11/30/2012 08:55 PM, Aaron O'Toole <airuno2L [..] ...> wrote:
> Hello all,
>
> Quick question: I have a 5 dof arm I need to do inverse position
> kinematics with (it doens't have a yaw joint). I've read through
> messages in the mailing list about this but am still having some
> trouble.
>
> This conversation has been of help:
> http://lists.mech.kuleuven.be/pipermail/orocos-users/2011-March/003255.html
>
> But I'm not sure how to follow through. I have:
>
> ChainFkSolverPos_recursive fksolver(chain);//Forward position solver
> ChainIkSolverVel_wdls iksolver1v(chain);//Inverse velocity solver
>
> Eigen::VectorXd weight_ts(6);
> weight_ts[1]=weight_ts[2]=weight_ts[3]=weight_ts[3]=weight_ts[4]=1.0;//X,Y,Z,roll
> pitch
> weight_ts[5]=0.0;//yaw
> iksolver1v.setWeightTS (weight_ts.asDiagonal());
>
> ChainIkSolverPos_NR iksolver1(chain,fksolver,iksolver1v,1000,1e-3);
> JntArray q(chain.getNrOfJoints());
> JntArray q_init(chain.getNrOfJoints());
>
> Frame F_dest=Frame(Rotation::RPY(-1.07, 0.94, 1.0), Vector(0.58,
> -0.38, -0.85));
> int ret = iksolver1.CartToJnt(q_init,F_dest,q);
>
>
> If I plug in a frame that I know my robot can acheive (including the
> yaw) the ik solver works, but if I just change the yaw value in F_dest
> it will fail and return -3, which tells me its not ignoring the yaw.
> Is there something else I need to do? Ruben mentions "adapt the
> ChainFkSolverPos_recursive to also take a TaskSpace Weight into
> account". Is this needed? Is it already implemented somewhere and I'm
> missing it? If I need to do implement it myself, can someone point me
> in the right direction?
>
> thanks,
> Aaron
>
>

Help with 5 DOF arm

Lol hey Erwin, thanks for the reply. I read someone mention this in
the mailing list when I was working on this problem and gave it a try.

If I was only worried about getting the end effector at a certain
position, this method worked well for me. However, I needed the end
effector at a certain orientation as well (I needed to solve for 5
dof...leaving out one angle). And since my actual end effector ended
up being the second to last link in the chain, I had no way of making
sure it was angled right. Does that make sense? I'll put it another
way just in case:

If the virtual frame is in the right position, then my end effector
frame has to be in the right position because the virtual link's
length is zero. However, if the virtual frame is in the right
orientation, my end effector frame will almost never be in the right
orientation because the virtual joint had to rotate to get to the
corrent orientation and it's axis of rotation can be any combination
of roll pitch or yaw depending on the arm's pose. The only time my end
effector frame will be oriented right is when my virtual joint's axis
of rotation happens to be parellel to the axis in which my arm is
lacking the 6th degree of freedom.

Let me know if I'm overlooking something here. I'm currently solving
IK by hand for this particular arm, while I'm using KDL for all my
other arms (which are 6 DOF). I'd love to go back and change it so
everything is more similar. It does seem that IKFast has the
capability I'm looking for, but I haven't wrapped my head around it
yet, I'm not sure if it can be used independant of OpenRave easily.

Thanks,
Aaron

On 1/4/13, Erwin Aertbelien <Erwin [dot] Aertbelien [..] ...> wrote:
> It suddenly occurred to me that the solution to your problem
> is easily solved with KDL, and I remembered your e-mail of 30 nov. 2012.
> (it's a pity I did not think of it sooner, because it is a commonly used
> method
> to deal with e.g. contact situations).
>
> The trick is to introduce a 6th _virtual_ joint. In this way an exact
> solution
> can be found. The solving of this new kinematic
> chain can then be done with KDL. After solving, you just ignore the
> virtual
> joint.
>
> In this way, you will not need any task space weights.
>
> Best regards,
>
> Erwin.
>
> On 11/30/2012 08:55 PM, Aaron O'Toole <airuno2L [..] ...> wrote:
>> Hello all,
>>
>> Quick question: I have a 5 dof arm I need to do inverse position
>> kinematics with (it doens't have a yaw joint). I've read through
>> messages in the mailing list about this but am still having some
>> trouble.
>>
>> This conversation has been of help:
>> http://lists.mech.kuleuven.be/pipermail/orocos-users/2011-March/003255.html
>>
>> But I'm not sure how to follow through. I have:
>>
>> ChainFkSolverPos_recursive fksolver(chain);//Forward position solver
>> ChainIkSolverVel_wdls iksolver1v(chain);//Inverse velocity solver
>>
>> Eigen::VectorXd weight_ts(6);
>> weight_ts[1]=weight_ts[2]=weight_ts[3]=weight_ts[3]=weight_ts[4]=1.0;//X,Y,Z,roll
>> pitch
>> weight_ts[5]=0.0;//yaw
>> iksolver1v.setWeightTS (weight_ts.asDiagonal());
>>
>> ChainIkSolverPos_NR iksolver1(chain,fksolver,iksolver1v,1000,1e-3);
>> JntArray q(chain.getNrOfJoints());
>> JntArray q_init(chain.getNrOfJoints());
>>
>> Frame F_dest=Frame(Rotation::RPY(-1.07, 0.94, 1.0), Vector(0.58,
>> -0.38, -0.85));
>> int ret = iksolver1.CartToJnt(q_init,F_dest,q);
>>
>>
>> If I plug in a frame that I know my robot can acheive (including the
>> yaw) the ik solver works, but if I just change the yaw value in F_dest
>> it will fail and return -3, which tells me its not ignoring the yaw.
>> Is there something else I need to do? Ruben mentions "adapt the
>> ChainFkSolverPos_recursive to also take a TaskSpace Weight into
>> account". Is this needed? Is it already implemented somewhere and I'm
>> missing it? If I need to do implement it myself, can someone point me
>> in the right direction?
>>
>> thanks,
>> Aaron
>>
>>
>
>

Help with 5 DOF arm

Err. I think I might have hinted at the correct solution when I said:

The only time my end
effector frame will be oriented right is when my virtual joint's axis
of rotation happens to be parellel to the axis in which my arm is
lacking the 6th degree of freedom.

I was assigning the 6th DOF willy nilly before. But I think if I put
more thought into it this method should work as desired, it will just
take a little geometry to figure out. I'll give it another try and
report back. Thanks for the inspiration guys.

Aaron.

On 1/4/13, Aaron O'Toole <airuno2L [..] ...> <airuno2l [..] ...> wrote:
> Lol hey Erwin, thanks for the reply. I read someone mention this in
> the mailing list when I was working on this problem and gave it a try.
>
> If I was only worried about getting the end effector at a certain
> position, this method worked well for me. However, I needed the end
> effector at a certain orientation as well (I needed to solve for 5
> dof...leaving out one angle). And since my actual end effector ended
> up being the second to last link in the chain, I had no way of making
> sure it was angled right. Does that make sense? I'll put it another
> way just in case:
>
> If the virtual frame is in the right position, then my end effector
> frame has to be in the right position because the virtual link's
> length is zero. However, if the virtual frame is in the right
> orientation, my end effector frame will almost never be in the right
> orientation because the virtual joint had to rotate to get to the
> corrent orientation and it's axis of rotation can be any combination
> of roll pitch or yaw depending on the arm's pose. The only time my end
> effector frame will be oriented right is when my virtual joint's axis
> of rotation happens to be parellel to the axis in which my arm is
> lacking the 6th degree of freedom.
>
> Let me know if I'm overlooking something here. I'm currently solving
> IK by hand for this particular arm, while I'm using KDL for all my
> other arms (which are 6 DOF). I'd love to go back and change it so
> everything is more similar. It does seem that IKFast has the
> capability I'm looking for, but I haven't wrapped my head around it
> yet, I'm not sure if it can be used independant of OpenRave easily.
>
> Thanks,
> Aaron
>
>
> On 1/4/13, Erwin Aertbelien <Erwin [dot] Aertbelien [..] ...> wrote:
>> It suddenly occurred to me that the solution to your problem
>> is easily solved with KDL, and I remembered your e-mail of 30 nov. 2012.
>> (it's a pity I did not think of it sooner, because it is a commonly used
>> method
>> to deal with e.g. contact situations).
>>
>> The trick is to introduce a 6th _virtual_ joint. In this way an exact
>> solution
>> can be found. The solving of this new kinematic
>> chain can then be done with KDL. After solving, you just ignore the
>> virtual
>> joint.
>>
>> In this way, you will not need any task space weights.
>>
>> Best regards,
>>
>> Erwin.
>>
>> On 11/30/2012 08:55 PM, Aaron O'Toole <airuno2L [..] ...> wrote:
>>> Hello all,
>>>
>>> Quick question: I have a 5 dof arm I need to do inverse position
>>> kinematics with (it doens't have a yaw joint). I've read through
>>> messages in the mailing list about this but am still having some
>>> trouble.
>>>
>>> This conversation has been of help:
>>> http://lists.mech.kuleuven.be/pipermail/orocos-users/2011-March/003255.html
>>>
>>> But I'm not sure how to follow through. I have:
>>>
>>> ChainFkSolverPos_recursive fksolver(chain);//Forward position solver
>>> ChainIkSolverVel_wdls iksolver1v(chain);//Inverse velocity solver
>>>
>>> Eigen::VectorXd weight_ts(6);
>>> weight_ts[1]=weight_ts[2]=weight_ts[3]=weight_ts[3]=weight_ts[4]=1.0;//X,Y,Z,roll
>>> pitch
>>> weight_ts[5]=0.0;//yaw
>>> iksolver1v.setWeightTS (weight_ts.asDiagonal());
>>>
>>> ChainIkSolverPos_NR iksolver1(chain,fksolver,iksolver1v,1000,1e-3);
>>> JntArray q(chain.getNrOfJoints());
>>> JntArray q_init(chain.getNrOfJoints());
>>>
>>> Frame F_dest=Frame(Rotation::RPY(-1.07, 0.94, 1.0), Vector(0.58,
>>> -0.38, -0.85));
>>> int ret = iksolver1.CartToJnt(q_init,F_dest,q);
>>>
>>>
>>> If I plug in a frame that I know my robot can acheive (including the
>>> yaw) the ik solver works, but if I just change the yaw value in F_dest
>>> it will fail and return -3, which tells me its not ignoring the yaw.
>>> Is there something else I need to do? Ruben mentions "adapt the
>>> ChainFkSolverPos_recursive to also take a TaskSpace Weight into
>>> account". Is this needed? Is it already implemented somewhere and I'm
>>> missing it? If I need to do implement it myself, can someone point me
>>> in the right direction?
>>>
>>> thanks,
>>> Aaron
>>>
>>>
>>
>>
>
>
> --
> - Aaron O'Toole
>

Help with 5 DOF arm

On Fri, 4 Jan 2013, Aaron O'Toole <airuno2L [..] ...> wrote:

> Err. I think I might have hinted at the correct solution when I said:
>
> The only time my end
> effector frame will be oriented right is when my virtual joint's axis
> of rotation happens to be parellel to the axis in which my arm is
> lacking the 6th degree of freedom.
>
> I was assigning the 6th DOF willy nilly before. But I think if I put
> more thought into it this method should work as desired, it will just
> take a little geometry to figure out. I'll give it another try and
> report back. Thanks for the inspiration guys.

You're welcome!

I am looking forward to getting some some case-specific insights from your
efforts :-)

> Aaron.

Herman

>
> On 1/4/13, Aaron O'Toole <airuno2L [..] ...> <airuno2l [..] ...> wrote:
>> Lol hey Erwin, thanks for the reply. I read someone mention this in
>> the mailing list when I was working on this problem and gave it a try.
>>
>> If I was only worried about getting the end effector at a certain
>> position, this method worked well for me. However, I needed the end
>> effector at a certain orientation as well (I needed to solve for 5
>> dof...leaving out one angle). And since my actual end effector ended
>> up being the second to last link in the chain, I had no way of making
>> sure it was angled right. Does that make sense? I'll put it another
>> way just in case:
>>
>> If the virtual frame is in the right position, then my end effector
>> frame has to be in the right position because the virtual link's
>> length is zero. However, if the virtual frame is in the right
>> orientation, my end effector frame will almost never be in the right
>> orientation because the virtual joint had to rotate to get to the
>> corrent orientation and it's axis of rotation can be any combination
>> of roll pitch or yaw depending on the arm's pose. The only time my end
>> effector frame will be oriented right is when my virtual joint's axis
>> of rotation happens to be parellel to the axis in which my arm is
>> lacking the 6th degree of freedom.
>>
>> Let me know if I'm overlooking something here. I'm currently solving
>> IK by hand for this particular arm, while I'm using KDL for all my
>> other arms (which are 6 DOF). I'd love to go back and change it so
>> everything is more similar. It does seem that IKFast has the
>> capability I'm looking for, but I haven't wrapped my head around it
>> yet, I'm not sure if it can be used independant of OpenRave easily.
>>
>> Thanks,
>> Aaron
>>
>>
>> On 1/4/13, Erwin Aertbelien <Erwin [dot] Aertbelien [..] ...> wrote:
>>> It suddenly occurred to me that the solution to your problem
>>> is easily solved with KDL, and I remembered your e-mail of 30 nov. 2012.
>>> (it's a pity I did not think of it sooner, because it is a commonly used
>>> method
>>> to deal with e.g. contact situations).
>>>
>>> The trick is to introduce a 6th _virtual_ joint. In this way an exact
>>> solution
>>> can be found. The solving of this new kinematic
>>> chain can then be done with KDL. After solving, you just ignore the
>>> virtual
>>> joint.
>>>
>>> In this way, you will not need any task space weights.
>>>
>>> Best regards,
>>>
>>> Erwin.
>>>
>>> On 11/30/2012 08:55 PM, Aaron O'Toole <airuno2L [..] ...> wrote:
>>>> Hello all,
>>>>
>>>> Quick question: I have a 5 dof arm I need to do inverse position
>>>> kinematics with (it doens't have a yaw joint). I've read through
>>>> messages in the mailing list about this but am still having some
>>>> trouble.
>>>>
>>>> This conversation has been of help:
>>>> http://lists.mech.kuleuven.be/pipermail/orocos-users/2011-March/003255.html
>>>>
>>>> But I'm not sure how to follow through. I have:
>>>>
>>>> ChainFkSolverPos_recursive fksolver(chain);//Forward position solver
>>>> ChainIkSolverVel_wdls iksolver1v(chain);//Inverse velocity solver
>>>>
>>>> Eigen::VectorXd weight_ts(6);
>>>> weight_ts[1]=weight_ts[2]=weight_ts[3]=weight_ts[3]=weight_ts[4]=1.0;//X,Y,Z,roll
>>>> pitch
>>>> weight_ts[5]=0.0;//yaw
>>>> iksolver1v.setWeightTS (weight_ts.asDiagonal());
>>>>
>>>> ChainIkSolverPos_NR iksolver1(chain,fksolver,iksolver1v,1000,1e-3);
>>>> JntArray q(chain.getNrOfJoints());
>>>> JntArray q_init(chain.getNrOfJoints());
>>>>
>>>> Frame F_dest=Frame(Rotation::RPY(-1.07, 0.94, 1.0), Vector(0.58,
>>>> -0.38, -0.85));
>>>> int ret = iksolver1.CartToJnt(q_init,F_dest,q);
>>>>
>>>>
>>>> If I plug in a frame that I know my robot can acheive (including the
>>>> yaw) the ik solver works, but if I just change the yaw value in F_dest
>>>> it will fail and return -3, which tells me its not ignoring the yaw.
>>>> Is there something else I need to do? Ruben mentions "adapt the
>>>> ChainFkSolverPos_recursive to also take a TaskSpace Weight into
>>>> account". Is this needed? Is it already implemented somewhere and I'm
>>>> missing it? If I need to do implement it myself, can someone point me
>>>> in the right direction?
>>>>
>>>> thanks,
>>>> Aaron
>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> - Aaron O'Toole
>>
>
>

Help with 5 DOF arm

On Fri, 4 Jan 2013, Erwin Aertbelien wrote:

> It suddenly occurred to me that the solution to your problem
> is easily solved with KDL, and I remembered your e-mail of 30 nov. 2012.
> (it's a pity I did not think of it sooner, because it is a commonly used
> method
> to deal with e.g. contact situations).
>
> The trick is to introduce a 6th _virtual_ joint. In this way an exact
> solution
> can be found. The solving of this new kinematic
> chain can then be done with KDL. After solving, you just ignore the virtual
> joint.
>
> In this way, you will not need any task space weights.

But I guess the _choice_ of the 6th virtual joint introduces some sort of
"weight" behind the screens, isn't it?

> Best regards,
>
> Erwin.

Herman

> On 11/30/2012 08:55 PM, Aaron O'Toole <airuno2L [..] ...> wrote:
>> Hello all,
>>
>> Quick question: I have a 5 dof arm I need to do inverse position
>> kinematics with (it doens't have a yaw joint). I've read through
>> messages in the mailing list about this but am still having some
>> trouble.
>>
>> This conversation has been of help:
>> http://lists.mech.kuleuven.be/pipermail/orocos-users/2011-March/003255.html
>>
>> But I'm not sure how to follow through. I have:
>>
>> ChainFkSolverPos_recursive fksolver(chain);//Forward position solver
>> ChainIkSolverVel_wdls iksolver1v(chain);//Inverse velocity solver
>>
>> Eigen::VectorXd weight_ts(6);
>> weight_ts[1]=weight_ts[2]=weight_ts[3]=weight_ts[3]=weight_ts[4]=1.0;//X,Y,Z,roll
>> pitch
>> weight_ts[5]=0.0;//yaw
>> iksolver1v.setWeightTS (weight_ts.asDiagonal());
>>
>> ChainIkSolverPos_NR iksolver1(chain,fksolver,iksolver1v,1000,1e-3);
>> JntArray q(chain.getNrOfJoints());
>> JntArray q_init(chain.getNrOfJoints());
>>
>> Frame F_dest=Frame(Rotation::RPY(-1.07, 0.94, 1.0), Vector(0.58,
>> -0.38, -0.85));
>> int ret = iksolver1.CartToJnt(q_init,F_dest,q);
>>
>>
>> If I plug in a frame that I know my robot can acheive (including the
>> yaw) the ik solver works, but if I just change the yaw value in F_dest
>> it will fail and return -3, which tells me its not ignoring the yaw.
>> Is there something else I need to do? Ruben mentions "adapt the
>> ChainFkSolverPos_recursive to also take a TaskSpace Weight into
>> account". Is this needed? Is it already implemented somewhere and I'm
>> missing it? If I need to do implement it myself, can someone point me
>> in the right direction?
>>
>> thanks,
>> Aaron
>>
>>
>

Help with 5 DOF arm

On 01/04/2013 01:07 PM, Herman Bruyninckx wrote:
> On Fri, 4 Jan 2013, Erwin Aertbelien wrote:
>
>> It suddenly occurred to me that the solution to your problem
>> is easily solved with KDL, and I remembered your e-mail of 30 nov. 2012.
>> (it's a pity I did not think of it sooner, because it is a commonly used
>> method
>> to deal with e.g. contact situations).
>>
>> The trick is to introduce a 6th _virtual_ joint. In this way an exact
>> solution
>> can be found. The solving of this new kinematic
>> chain can then be done with KDL. After solving, you just ignore the
>> virtual
>> joint.
>>
>> In this way, you will not need any task space weights.
>
> But I guess the _choice_ of the 6th virtual joint introduces some sort of
> "weight" behind the screens, isn't it?
Yes, with this method, you indicate a direction (not necessarily
rotational).
You do not care about deviations around this direction.
This is equivalent to specifying a weight matrix (in twist/displacement
space) that has this direction in its null-space.

The point is, that the proposed way is very easy to implement.

But, you're right, you'll have to think about exactly which direction
you want to set free.

Note: sometimes the specification suggests a way to specify this 6th
virtual joint. E.g. in 5-axis milling machines,
the robot pose is often specified using a tool tip position and a
normalized orientation
vector. This specification implicitly specifies that the orientation
around this normalized orientation vector
does not matter.

Also the kinematics of the device can suggest a 6th virtual joint, e.g.
with a 5-axis paletizing robot.

Erwin.
>
>> Best regards,
>>
>> Erwin.
>
> Herman
>
>> On 11/30/2012 08:55 PM, Aaron O'Toole <airuno2L [..] ...> wrote:
>>> Hello all,
>>>
>>> Quick question: I have a 5 dof arm I need to do inverse position
>>> kinematics with (it doens't have a yaw joint). I've read through
>>> messages in the mailing list about this but am still having some
>>> trouble.
>>>
>>> This conversation has been of help:
>>> http://lists.mech.kuleuven.be/pipermail/orocos-users/2011-March/003255.html
>>>
>>>
>>> But I'm not sure how to follow through. I have:
>>>
>>> ChainFkSolverPos_recursive fksolver(chain);//Forward position solver
>>> ChainIkSolverVel_wdls iksolver1v(chain);//Inverse velocity solver
>>>
>>> Eigen::VectorXd weight_ts(6);
>>> weight_ts[1]=weight_ts[2]=weight_ts[3]=weight_ts[3]=weight_ts[4]=1.0;//X,Y,Z,roll
>>>
>>> pitch
>>> weight_ts[5]=0.0;//yaw
>>> iksolver1v.setWeightTS (weight_ts.asDiagonal());
>>>
>>> ChainIkSolverPos_NR iksolver1(chain,fksolver,iksolver1v,1000,1e-3);
>>> JntArray q(chain.getNrOfJoints());
>>> JntArray q_init(chain.getNrOfJoints());
>>>
>>> Frame F_dest=Frame(Rotation::RPY(-1.07, 0.94, 1.0), Vector(0.58,
>>> -0.38, -0.85));
>>> int ret = iksolver1.CartToJnt(q_init,F_dest,q);
>>>
>>>
>>> If I plug in a frame that I know my robot can acheive (including the
>>> yaw) the ik solver works, but if I just change the yaw value in F_dest
>>> it will fail and return -3, which tells me its not ignoring the yaw.
>>> Is there something else I need to do? Ruben mentions "adapt the
>>> ChainFkSolverPos_recursive to also take a TaskSpace Weight into
>>> account". Is this needed? Is it already implemented somewhere and I'm
>>> missing it? If I need to do implement it myself, can someone point me
>>> in the right direction?
>>>
>>> thanks,
>>> Aaron
>>>
>>>
>>

Help with 5 DOF arm

On Fri, 4 Jan 2013, Erwin Aertbelien wrote:

> On 01/04/2013 01:07 PM, Herman Bruyninckx wrote:
>> On Fri, 4 Jan 2013, Erwin Aertbelien wrote:
>>
>>> It suddenly occurred to me that the solution to your problem
>>> is easily solved with KDL, and I remembered your e-mail of 30 nov. 2012.
>>> (it's a pity I did not think of it sooner, because it is a commonly used
>>> method
>>> to deal with e.g. contact situations).
>>>
>>> The trick is to introduce a 6th _virtual_ joint. In this way an exact
>>> solution
>>> can be found. The solving of this new kinematic
>>> chain can then be done with KDL. After solving, you just ignore the
>>> virtual
>>> joint.
>>>
>>> In this way, you will not need any task space weights.
>>
>> But I guess the _choice_ of the 6th virtual joint introduces some sort of
>> "weight" behind the screens, isn't it?
> Yes, with this method, you indicate a direction (not necessarily rotational).
> You do not care about deviations around this direction.
> This is equivalent to specifying a weight matrix (in twist/displacement
> space) that has this direction in its null-space.

This idea was (I think) originally introduced in the robotics domain by
John Baillieul, at the ICRA 1985 (Kinematic programming alternatives for redundant
manipulators, 722-728). He extends the 6xn (n<6) Jacobian with 6-n extra
rows; hence, the name "extended Jacoboan" method.

> The point is, that the proposed way is very easy to implement.
>
> But, you're right, you'll have to think about exactly which direction you
> want to set free.
>
> Note: sometimes the specification suggests a way to specify this 6th
> virtual joint.

Agreed.

> E.g. in 5-axis milling machines, the robot pose is often
> specified using a tool tip position and a normalized orientation vector.
> This specification implicitly specifies that the orientation around this
> normalized orientation vector does not matter.
>
> Also the kinematics of the device can suggest a 6th virtual joint, e.g. with
> a 5-axis paletizing robot.
>
> Erwin.

Herman

>>> On 11/30/2012 08:55 PM, Aaron O'Toole <airuno2L [..] ...> wrote:
>>>> Hello all,
>>>>
>>>> Quick question: I have a 5 dof arm I need to do inverse position
>>>> kinematics with (it doens't have a yaw joint). I've read through
>>>> messages in the mailing list about this but am still having some
>>>> trouble.
>>>>
>>>> This conversation has been of help:
>>>> http://lists.mech.kuleuven.be/pipermail/orocos-users/2011-March/003255.html
>>>>
>>>> But I'm not sure how to follow through. I have:
>>>>
>>>> ChainFkSolverPos_recursive fksolver(chain);//Forward position solver
>>>> ChainIkSolverVel_wdls iksolver1v(chain);//Inverse velocity solver
>>>>
>>>> Eigen::VectorXd weight_ts(6);
>>>> weight_ts[1]=weight_ts[2]=weight_ts[3]=weight_ts[3]=weight_ts[4]=1.0;//X,Y,Z,roll
>>>> pitch
>>>> weight_ts[5]=0.0;//yaw
>>>> iksolver1v.setWeightTS (weight_ts.asDiagonal());
>>>>
>>>> ChainIkSolverPos_NR iksolver1(chain,fksolver,iksolver1v,1000,1e-3);
>>>> JntArray q(chain.getNrOfJoints());
>>>> JntArray q_init(chain.getNrOfJoints());
>>>>
>>>> Frame F_dest=Frame(Rotation::RPY(-1.07, 0.94, 1.0), Vector(0.58,
>>>> -0.38, -0.85));
>>>> int ret = iksolver1.CartToJnt(q_init,F_dest,q);
>>>>
>>>>
>>>> If I plug in a frame that I know my robot can acheive (including the
>>>> yaw) the ik solver works, but if I just change the yaw value in F_dest
>>>> it will fail and return -3, which tells me its not ignoring the yaw.
>>>> Is there something else I need to do? Ruben mentions "adapt the
>>>> ChainFkSolverPos_recursive to also take a TaskSpace Weight into
>>>> account". Is this needed? Is it already implemented somewhere and I'm
>>>> missing it? If I need to do implement it myself, can someone point me
>>>> in the right direction?
>>>>
>>>> thanks,
>>>> Aaron
>>>>
>>>>
>>>
>>> --
>>> Orocos-Users mailing list
>>> Orocos-Users [..] ...
>>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>>
>>
>> --
>> KU Leuven, Mechanical Engineering, Robotics Research Group
>> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
>> Vice-President Research euRobotics <http://www.eu-robotics.net>
>> Open RObot COntrol Software <http://www.orocos.org>
>> Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
>
>

--
KU Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
Vice-President Research euRobotics <http://www.eu-robotics.net>
Open RObot COntrol Software <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>

Help with 5 DOF arm

On 01/04/2013 01:50 PM, Herman Bruyninckx wrote:
> On Fri, 4 Jan 2013, Erwin Aertbelien wrote:
>
>> On 01/04/2013 01:07 PM, Herman Bruyninckx wrote:
>>> On Fri, 4 Jan 2013, Erwin Aertbelien wrote:
>>>
>>>> It suddenly occurred to me that the solution to your problem
>>>> is easily solved with KDL, and I remembered your e-mail of 30 nov.
>>>> 2012.
>>>> (it's a pity I did not think of it sooner, because it is a commonly
>>>> used
>>>> method
>>>> to deal with e.g. contact situations).
>>>>
>>>> The trick is to introduce a 6th _virtual_ joint. In this way an exact
>>>> solution
>>>> can be found. The solving of this new kinematic
>>>> chain can then be done with KDL. After solving, you just ignore
>>>> the virtual
>>>> joint.
>>>>
>>>> In this way, you will not need any task space weights.
>>>
>>> But I guess the _choice_ of the 6th virtual joint introduces some
>>> sort of
>>> "weight" behind the screens, isn't it?
>> Yes, with this method, you indicate a direction (not necessarily
>> rotational).
>> You do not care about deviations around this direction.
>> This is equivalent to specifying a weight matrix (in
>> twist/displacement space) that has this direction in its null-space.
>
> This idea was (I think) originally introduced in the robotics domain by
> John Baillieul, at the ICRA 1985 (Kinematic programming alternatives
> for redundant
> manipulators, 722-728). He extends the 6xn (n<6) Jacobian with 6-n extra
> rows; hence, the name "extended Jacoboan" method.
If I remember the article well, the current problem here is some kind of
"dual" of the problem of Bailleul.
(redundant <-> not enough dof, to little constraints <-> to many
constraints)

The nice thing of the extended Jacobian is that the solution is
"integrable" (i.e. for a repetitive task space specification,
the joint space motions will also be repetitive). This property remains
valid in the current example.

>
>> The point is, that the proposed way is very easy to implement.
>>
>> But, you're right, you'll have to think about exactly which direction
>> you want to set free.
>>
>> Note: sometimes the specification suggests a way to specify this 6th
>> virtual joint.
>
> Agreed.
>
>> E.g. in 5-axis milling machines, the robot pose is often
>> specified using a tool tip position and a normalized orientation vector.
>> This specification implicitly specifies that the orientation around this
>> normalized orientation vector does not matter.
>>
>> Also the kinematics of the device can suggest a 6th virtual joint,
>> e.g. with a 5-axis paletizing robot.
>>
>> Erwin.
>
> Herman
>
>>>> On 11/30/2012 08:55 PM, Aaron O'Toole <airuno2L [..] ...> wrote:
>>>>> Hello all,
>>>>>
>>>>> Quick question: I have a 5 dof arm I need to do inverse position
>>>>> kinematics with (it doens't have a yaw joint). I've read through
>>>>> messages in the mailing list about this but am still having some
>>>>> trouble.
>>>>>
>>>>> This conversation has been of help:
>>>>> http://lists.mech.kuleuven.be/pipermail/orocos-users/2011-March/003255.html
>>>>>
>>>>> But I'm not sure how to follow through. I have:
>>>>>
>>>>> ChainFkSolverPos_recursive fksolver(chain);//Forward position solver
>>>>> ChainIkSolverVel_wdls iksolver1v(chain);//Inverse velocity solver
>>>>>
>>>>> Eigen::VectorXd weight_ts(6);
>>>>> weight_ts[1]=weight_ts[2]=weight_ts[3]=weight_ts[3]=weight_ts[4]=1.0;//X,Y,Z,roll
>>>>> pitch
>>>>> weight_ts[5]=0.0;//yaw
>>>>> iksolver1v.setWeightTS (weight_ts.asDiagonal());
>>>>>
>>>>> ChainIkSolverPos_NR iksolver1(chain,fksolver,iksolver1v,1000,1e-3);
>>>>> JntArray q(chain.getNrOfJoints());
>>>>> JntArray q_init(chain.getNrOfJoints());
>>>>>
>>>>> Frame F_dest=Frame(Rotation::RPY(-1.07, 0.94, 1.0), Vector(0.58,
>>>>> -0.38, -0.85));
>>>>> int ret = iksolver1.CartToJnt(q_init,F_dest,q);
>>>>>
>>>>>
>>>>> If I plug in a frame that I know my robot can acheive (including the
>>>>> yaw) the ik solver works, but if I just change the yaw value in
>>>>> F_dest
>>>>> it will fail and return -3, which tells me its not ignoring the yaw.
>>>>> Is there something else I need to do? Ruben mentions "adapt the
>>>>> ChainFkSolverPos_recursive to also take a TaskSpace Weight into
>>>>> account". Is this needed? Is it already implemented somewhere and I'm
>>>>> missing it? If I need to do implement it myself, can someone point me
>>>>> in the right direction?
>>>>>
>>>>> thanks,
>>>>> Aaron
>>>>>
>>>>>
>>>>
>>>> --
>>>> Orocos-Users mailing list
>>>> Orocos-Users [..] ...
>>>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>>>
>>>
>>> --
>>> KU Leuven, Mechanical Engineering, Robotics Research Group
>>> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
>>> Vice-President Research euRobotics <http://www.eu-robotics.net>
>>> Open RObot COntrol Software <http://www.orocos.org>
>>> Associate Editor JOSER <http://www.joser.org>, IJRR
>>> <http://www.ijrr.org>
>>
>>
>

Help with 5 DOF arm

On Fri, 30 Nov 2012, Aaron O'Toole <airuno2L [..] ...> wrote:

> Hello all,
>
> Quick question: I have a 5 dof arm I need to do inverse position
> kinematics with (it doens't have a yaw joint). I've read through
> messages in the mailing list about this but am still having some
> trouble.
>
> This conversation has been of help:
> http://lists.mech.kuleuven.be/pipermail/orocos-users/2011-March/003255.html
>
> But I'm not sure how to follow through. I have:
>
> ChainFkSolverPos_recursive fksolver(chain);//Forward position solver
> ChainIkSolverVel_wdls iksolver1v(chain);//Inverse velocity solver
>
> Eigen::VectorXd weight_ts(6);
> weight_ts[1]=weight_ts[2]=weight_ts[3]=weight_ts[3]=weight_ts[4]=1.0;//X,Y,Z,roll
> pitch
> weight_ts[5]=0.0;//yaw
> iksolver1v.setWeightTS (weight_ts.asDiagonal());
>
> ChainIkSolverPos_NR iksolver1(chain,fksolver,iksolver1v,1000,1e-3);
> JntArray q(chain.getNrOfJoints());
> JntArray q_init(chain.getNrOfJoints());
>
> Frame F_dest=Frame(Rotation::RPY(-1.07, 0.94, 1.0), Vector(0.58,
> -0.38, -0.85));
> int ret = iksolver1.CartToJnt(q_init,F_dest,q);
>
>
> If I plug in a frame that I know my robot can acheive (including the
> yaw) the ik solver works, but if I just change the yaw value in F_dest
> it will fail and return -3, which tells me its not ignoring the yaw.
> Is there something else I need to do? Ruben mentions "adapt the
> ChainFkSolverPos_recursive to also take a TaskSpace Weight into
> account". Is this needed?

By definition: if your structure can physically not reach the given frame,
you have to give your solver a distance function to minimize the allowed
error between what you want and what your structure can provide.

The error behaviour of your code could come from the fact that the
numerical interation does not converge to where you want it to converge...

> Is it already implemented somewhere and I'm
> missing it? If I need to do implement it myself, can someone point me
> in the right direction?

The " ChainIkSolverVel_wdls" already has both joint space and task space
weighting matrices:
<http://people.mech.kuleuven.be/~rsmits/kdl/api/html/classKDL_1_1ChainIkSolverVel__wdls.html#_details>
And the code fragment you included already use that: "setWeightTS".

> thanks,
> Aaron
>

Herman

Help with 5 DOF arm

On 12/02/2012 12:10 PM, Herman Bruyninckx wrote:
> On Fri, 30 Nov 2012, Aaron O'Toole <airuno2L [..] ...> wrote:
>
>> Hello all,
>>
>> Quick question: I have a 5 dof arm I need to do inverse position
>> kinematics with (it doens't have a yaw joint). I've read through
>> messages in the mailing list about this but am still having some
>> trouble.
>>
>> This conversation has been of help:
>> http://lists.mech.kuleuven.be/pipermail/orocos-users/2011-March/003255.html
>>
>> But I'm not sure how to follow through. I have:
>>
>> ChainFkSolverPos_recursive fksolver(chain);//Forward position solver
>> ChainIkSolverVel_wdls iksolver1v(chain);//Inverse velocity solver
>>
>> Eigen::VectorXd weight_ts(6);
>> weight_ts[1]=weight_ts[2]=weight_ts[3]=weight_ts[3]=weight_ts[4]=1.0;//X,Y,Z,roll
>> pitch
>> weight_ts[5]=0.0;//yaw
>> iksolver1v.setWeightTS (weight_ts.asDiagonal());
>>
>> ChainIkSolverPos_NR iksolver1(chain,fksolver,iksolver1v,1000,1e-3);
>> JntArray q(chain.getNrOfJoints());
>> JntArray q_init(chain.getNrOfJoints());
>>
>> Frame F_dest=Frame(Rotation::RPY(-1.07, 0.94, 1.0), Vector(0.58,
>> -0.38, -0.85));
>> int ret = iksolver1.CartToJnt(q_init,F_dest,q);
>>
>>
>> If I plug in a frame that I know my robot can acheive (including the
>> yaw) the ik solver works, but if I just change the yaw value in F_dest
>> it will fail and return -3, which tells me its not ignoring the yaw.
>> Is there something else I need to do? Ruben mentions "adapt the
>> ChainFkSolverPos_recursive to also take a TaskSpace Weight into
>> account". Is this needed?
> By definition: if your structure can physically not reach the given frame,
> you have to give your solver a distance function to minimize the allowed
> error between what you want and what your structure can provide.
>
> The error behaviour of your code could come from the fact that the
> numerical interation does not converge to where you want it to converge...
>
>> Is it already implemented somewhere and I'm
>> missing it? If I need to do implement it myself, can someone point me
>> in the right direction?
> The " ChainIkSolverVel_wdls" already has both joint space and task space
> weighting matrices:
> <http://people.mech.kuleuven.be/~rsmits/kdl/api/html/classKDL_1_1ChainIkSolverVel__wdls.html#_details>
> And the code fragment you included already use that: "setWeightTS".
But the above is _velocity_ kinematics, if you want inverse pos.
kinematics, also the convergence criteria inside
the pos. solver should be weighted. This is currently not the case.

The recent levenberg-marquardt inv. pos. kinematics solver
ChainIkSolverPos_LMA has
weights, but it has two problems for this use case:
- only a diagonal weight matrix can be specified.
- you cannot adapt the weight matrix between calls, it is initialized
in the constructor.

The above points are problematic, since in the given case the
orientation of the "missing" yaw axis
is changing each time, and the weight matrix has to be adapted to
exactly the directions of this axis.
Also, ChainIkSolverPos_LMA does not take into account joint limits.

It is time to refactor ChainIkSolverPos_LMA...

It is also important to notice, that, if you are also working with
Orocos-RTT, you can
also use our iTasc framework to solve the above problems. (
http://www.orocos.org/wiki/orocos/itasc-wiki)
But be warned, this framework goes much further than the above inv. kin.
problem and requires some
significant effort to learn the principles behind it.
>
>> thanks,
>> Aaron
>>
> Herman

Help with 5 DOF arm

Dear Erwin,

A pos solver that integrates weightings would be a wonderful contribution.
I recall this [1] thread on a solver based on ChainIkSolverPos_NR_JL that
takes weighting into account, source code is posted [2].
Possible this is relevant to this discussion?

-jelle

[1] http://ros-users.122217.n3.nabble.com/IK-with-KDL-td1867716.html
[2]
http://ros-users.122217.n3.nabble.com/attachment/2055076/0/iksolvers_wei...

> But the above is _velocity_ kinematics, if you want inverse pos.
> kinematics, also the convergence criteria inside
> the pos. solver should be weighted. This is currently not the case.
>
> The recent levenberg-marquardt inv. pos. kinematics solver
> ChainIkSolverPos_LMA has
> weights, but it has two problems for this use case:
> - only a diagonal weight matrix can be specified.
> - you cannot adapt the weight matrix between calls, it is initialized in
> the constructor.
>
> The above points are problematic, since in the given case the orientation
> of the "missing" yaw axis
> is changing each time, and the weight matrix has to be adapted to exactly
> the directions of this axis.
> Also, ChainIkSolverPos_LMA does not take into account joint limits.
>
> It is time to refactor ChainIkSolverPos_LMA...
>

Help with 5 DOF arm

On 12/02/2012 02:26 PM, jelle feringa wrote:
> Dear Erwin,
>
> A pos solver that integrates weightings would be a wonderful contribution.
Yes it would be interesting, an extension of the solver that solves
towards more
general constraints would even be more interesting, but then were
getting into iTaSC territory...

> I recall this [1] thread on a solver based on ChainIkSolverPos_NR_JL
> that takes weighting into account, source code is posted [2].
Yes it is relevant. Strange thing is that the code does not match the
explanations in the mail.
pibgeustalks about weights on xyz RPY but in the code the weights are on
the displacement twist (i.e. the result of KDL's diff(..) )

You should also be sure to use a weighted inv. vel. kin.

Has anyone tried out this solver ?

However, this would not completely solved the problems with the 5 dof
robots, since the weights are still
a diagonal matrix. With these type of weights you cannot specify that
the rotation along a given axes is irrelevant.
You'll need a full symmetric matrix ( or its square root) to specify
such a thing. And even with a full symmetric matrix
it will be annoying to use (because you have to construct the weighing
matrix and that requires some insight).
Better would be in this case to be able to specify the weighing matrix
relative to the end effector.

But you see, there are a lot of use cases, that require different
variants of solvers, ...

Interested people can submit a feature request in our bug tracking
system (bugs.orocos.org), together with
the information below. Then, at least, we are not forgetting about
these type of issues, when we are considering
changes to KDL.

Best regards,
Erwin.
> Possible this is relevant to this discussion?
>
> -jelle
>
> [1] http://ros-users.122217.n3.nabble.com/IK-with-KDL-td1867716.html
> [2]
> http://ros-users.122217.n3.nabble.com/attachment/2055076/0/iksolvers_wei...
>
> But the above is _velocity_ kinematics, if you want inverse pos.
> kinematics, also the convergence criteria inside
> the pos. solver should be weighted. This is currently not the case.
>
> The recent levenberg-marquardt inv. pos. kinematics solver
> ChainIkSolverPos_LMA has
> weights, but it has two problems for this use case:
> - only a diagonal weight matrix can be specified.
> - you cannot adapt the weight matrix between calls, it is
> initialized in the constructor.
>
> The above points are problematic, since in the given case the
> orientation of the "missing" yaw axis
> is changing each time, and the weight matrix has to be adapted to
> exactly the directions of this axis.
> Also, ChainIkSolverPos_LMA does not take into account joint limits.
>
> It is time to refactor ChainIkSolverPos_LMA...
>
>
>

Help with 5 DOF arm

What type of robot are you using? A typical 5-dof welding robot ?

If it is a robot with its last 2 axes intersecting in 1 point, an
analytical solution to
the inverse position kinematics exists:

* Such a solution is prefered above numerical solution.
* "Pieper's solution" to the inverse kinematics of a 3-2-1 robot can be
an inspiration (cfr. any textbook on robotics):
you split up the inverse kinematics problem into a part involving the 3
first joints and a part involving the
last 3 joints. For that last parts the KDL routines for euler angles or
rpy angles could be useful.

Best regards,
Erwin.

On 11/30/2012 08:55 PM, Aaron O'Toole <airuno2L [..] ...> wrote:
> Hello all,
>
> Quick question: I have a 5 dof arm I need to do inverse position
> kinematics with (it doens't have a yaw joint). I've read through
> messages in the mailing list about this but am still having some
> trouble.
>
> This conversation has been of help:
> http://lists.mech.kuleuven.be/pipermail/orocos-users/2011-March/003255.html
>
> But I'm not sure how to follow through. I have:
>
> ChainFkSolverPos_recursive fksolver(chain);//Forward position solver
> ChainIkSolverVel_wdls iksolver1v(chain);//Inverse velocity solver
>
> Eigen::VectorXd weight_ts(6);
> weight_ts[1]=weight_ts[2]=weight_ts[3]=weight_ts[3]=weight_ts[4]=1.0;//X,Y,Z,roll
> pitch
> weight_ts[5]=0.0;//yaw
> iksolver1v.setWeightTS (weight_ts.asDiagonal());
>
> ChainIkSolverPos_NR iksolver1(chain,fksolver,iksolver1v,1000,1e-3);
> JntArray q(chain.getNrOfJoints());
> JntArray q_init(chain.getNrOfJoints());
>
> Frame F_dest=Frame(Rotation::RPY(-1.07, 0.94, 1.0), Vector(0.58,
> -0.38, -0.85));
> int ret = iksolver1.CartToJnt(q_init,F_dest,q);
>
>
> If I plug in a frame that I know my robot can acheive (including the
> yaw) the ik solver works, but if I just change the yaw value in F_dest
> it will fail and return -3, which tells me its not ignoring the yaw.
> Is there something else I need to do? Ruben mentions "adapt the
> ChainFkSolverPos_recursive to also take a TaskSpace Weight into
> account". Is this needed? Is it already implemented somewhere and I'm
> missing it? If I need to do implement it myself, can someone point me
> in the right direction?
>
> thanks,
> Aaron
>
>

Help with 5 DOF arm

I would suggest using
http://openrave.org/docs/latest_stable/openravepy/ikfast/ to generate
closed-form ik and using numerical ik only if ikfast can't solve your type
of kinematic chain.

Pozdrawiam
Konrad Banachowicz

2012/11/30 Erwin Aertbelien <Erwin [dot] Aertbelien [..] ...>

> What type of robot are you using? A typical 5-dof welding robot ?
>
> If it is a robot with its last 2 axes intersecting in 1 point, an
> analytical solution to
> the inverse position kinematics exists:
>
> * Such a solution is prefered above numerical solution.
> * "Pieper's solution" to the inverse kinematics of a 3-2-1 robot can be
> an inspiration (cfr. any textbook on robotics):
> you split up the inverse kinematics problem into a part involving the 3
> first joints and a part involving the
> last 3 joints. For that last parts the KDL routines for euler angles or
> rpy angles could be useful.
>
> Best regards,
> Erwin.
>
>
> On 11/30/2012 08:55 PM, Aaron O'Toole <airuno2L [..] ...> wrote:
> > Hello all,
> >
> > Quick question: I have a 5 dof arm I need to do inverse position
> > kinematics with (it doens't have a yaw joint). I've read through
> > messages in the mailing list about this but am still having some
> > trouble.
> >
> > This conversation has been of help:
> >
> http://lists.mech.kuleuven.be/pipermail/orocos-users/2011-March/003255.html
> >
> > But I'm not sure how to follow through. I have:
> >
> > ChainFkSolverPos_recursive fksolver(chain);//Forward position solver
> > ChainIkSolverVel_wdls iksolver1v(chain);//Inverse velocity solver
> >
> > Eigen::VectorXd weight_ts(6);
> >
> weight_ts[1]=weight_ts[2]=weight_ts[3]=weight_ts[3]=weight_ts[4]=1.0;//X,Y,Z,roll
> > pitch
> > weight_ts[5]=0.0;//yaw
> > iksolver1v.setWeightTS (weight_ts.asDiagonal());
> >
> > ChainIkSolverPos_NR iksolver1(chain,fksolver,iksolver1v,1000,1e-3);
> > JntArray q(chain.getNrOfJoints());
> > JntArray q_init(chain.getNrOfJoints());
> >
> > Frame F_dest=Frame(Rotation::RPY(-1.07, 0.94, 1.0), Vector(0.58,
> > -0.38, -0.85));
> > int ret = iksolver1.CartToJnt(q_init,F_dest,q);
> >
> >
> > If I plug in a frame that I know my robot can acheive (including the
> > yaw) the ik solver works, but if I just change the yaw value in F_dest
> > it will fail and return -3, which tells me its not ignoring the yaw.
> > Is there something else I need to do? Ruben mentions "adapt the
> > ChainFkSolverPos_recursive to also take a TaskSpace Weight into
> > account". Is this needed? Is it already implemented somewhere and I'm
> > missing it? If I need to do implement it myself, can someone point me
> > in the right direction?
> >
> > thanks,
> > Aaron
> >
> >
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

Help with 5 DOF arm

On Sat, 1 Dec 2012, Konrad Banachowicz wrote:

> I would suggest using http://openrave.org/docs/latest_stable/openravepy/ikfast/ to generate
> closed-form ik and using numerical ik only if ikfast can't solve your type of kinematic chain.

Which is almost always the case. Because real robotics systems do a lot
more than just computing inverse/forward position kinematics: they add
control, optimization, dynamics, estimation, joint limit avoidance,
actuator limit monitoring,... into the computations of the kinematics. And
there are no closed form solutions for those.

However, KDL has very efficient closed form solutions too, for the
traditional 6-DOF industrial robot kinematics.

> Pozdrawiam
> Konrad Banachowicz

Herman

> 2012/11/30 Erwin Aertbelien <Erwin [dot] Aertbelien [..] ...>
> What type of robot are you using? A typical 5-dof welding robot ?
>
> If it is a robot with its last 2 axes intersecting in 1 point, an
> analytical solution to
> the inverse position kinematics exists:
>
> *  Such a solution is prefered above numerical solution.
> * "Pieper's solution" to the inverse kinematics of a 3-2-1 robot can be
> an inspiration (cfr. any textbook on robotics):
> you split up the inverse kinematics problem into a part involving the 3
> first joints and a part involving the
> last 3 joints.  For that last parts the KDL routines for euler angles or
> rpy angles could be useful.
>
> Best regards,
> Erwin.
>
>
> On 11/30/2012 08:55 PM, Aaron O'Toole <airuno2L [..] ...> wrote:
> > Hello all,
> >
> > Quick question: I have a 5 dof arm I need to do inverse position
> > kinematics with (it doens't have a yaw joint). I've read through
> > messages in the mailing list about this but am still having some
> > trouble.
> >
> > This conversation has been of help:
> > http://lists.mech.kuleuven.be/pipermail/orocos-users/2011-March/003255.html
> >
> > But I'm not sure how to follow through. I have:
> >
> > ChainFkSolverPos_recursive fksolver(chain);//Forward position solver
> > ChainIkSolverVel_wdls iksolver1v(chain);//Inverse velocity solver
> >
> > Eigen::VectorXd weight_ts(6);
> > weight_ts[1]=weight_ts[2]=weight_ts[3]=weight_ts[3]=weight_ts[4]=1.0;//X,Y,Z,roll
> > pitch
> > weight_ts[5]=0.0;//yaw
> > iksolver1v.setWeightTS (weight_ts.asDiagonal());
> >
> > ChainIkSolverPos_NR iksolver1(chain,fksolver,iksolver1v,1000,1e-3);
> > JntArray q(chain.getNrOfJoints());
> > JntArray q_init(chain.getNrOfJoints());
> >
> > Frame F_dest=Frame(Rotation::RPY(-1.07, 0.94, 1.0), Vector(0.58,
> > -0.38, -0.85));
> > int ret = iksolver1.CartToJnt(q_init,F_dest,q);
> >
> >
> > If I plug in a frame that I know my robot can acheive (including the
> > yaw) the ik solver works, but if I just change the yaw value in F_dest
> > it will fail and return -3, which tells me its not ignoring the yaw.
> > Is there something else I need to do? Ruben mentions "adapt the
> > ChainFkSolverPos_recursive to also take a TaskSpace Weight into
> > account". Is this needed? Is it already implemented somewhere and I'm
> > missing it? If I need to do implement it myself, can someone point me
> > in the right direction?
> >
> > thanks,
> > Aaron
> >
> >
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>
>
>

--
KU Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
Vice-President Research euRobotics <http://www.eu-robotics.net>
Open RObot COntrol Software <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>

Help with 5 DOF arm

On Sun, Dec 2, 2012 at 5:59 AM, Herman Bruyninckx <
Herman [dot] Bruyninckx [..] ...> wrote:

> Because real robotics systems do a lot
> more than just computing inverse/forward position kinematics
>

I'm working with "real robotics systems" and I only need inverse kinematics

control - is taken care of per joint motor
optimization - doesn't matter in my application
dynamics - also doesn't matter
estimation - not sure what you mean there
joint limit avoidance - I consider this part of the kinematics problem
actuator limit monitoring - is taken care of per joint motor.

Help with 5 DOF arm

On Mon, 3 Dec 2012, Aaron O'Toole <airuno2L [..] ...> wrote:

>
>
> On Sun, Dec 2, 2012 at 5:59 AM, Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...> wrote:
> Because real robotics systems do a lot
> more than just computing inverse/forward position kinematics
>
>
> I'm working with "real robotics systems" and I only need inverse kinematics
>
> control - is taken care of per joint motor

Also at that level, interpolation is needed. If a controller takes care of
that interpolation, fine, but the properties of the controller should then
be taken into account in the IK.

> optimization - doesn't matter in my application
> dynamics - also doesn't matter

I see... If neither of these two aspects matter, then I rest my case.
Nevertheless, every weighthing of Cartesian or joint space errors _is_ an
optimization, and _does_ reflect dynamics.

> estimation - not sure what you mean there

Using sensors to deal with the difference between the real world and the
one that your robot controller has a model of. This "uncertainty"
influences the above-mentioned optimization: there is no need to solve the
kinematics with a higher accuracy then what the sensors can provide. More
in particular, this influences the "epsilon" tolerance parameter that
occurs on many numerical solvers.

> joint limit avoidance - I consider this part of the kinematics problem

Me too. And also here, dynamics and optimization sneak in, often
implicitly, since the application developer has to choose a particular
"policy" to do joint limit avoidance.

> actuator limit monitoring - is taken care of per joint motor. 

If those limits are known, the "IK" solver could try to avoid reaching
these limits.

> --
> - Aaron O'Toole

Herman

>

--
KU Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
Vice-President Research euRobotics <http://www.eu-robotics.net>
Open RObot COntrol Software <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>

Help with 5 DOF arm

On 12/02/2012 11:59 AM, Herman Bruyninckx wrote:
> On Sat, 1 Dec 2012, Konrad Banachowicz wrote:
>
>> I would suggest using http://openrave.org/docs/latest_stable/openravepy/ikfast/ to generate
>> closed-form ik and using numerical ik only if ikfast can't solve your type of kinematic chain.
> Which is almost always the case. Because real robotics systems do a lot
> more than just computing inverse/forward position kinematics: they add
> control, optimization, dynamics, estimation, joint limit avoidance,
> actuator limit monitoring,... into the computations of the kinematics. And
> there are no closed form solutions for those.
>
> However, KDL has very efficient closed form solutions too, for the
> traditional 6-DOF industrial robot kinematics.
Not any more,
several years ago, Ruben removed these routines from KDL.

>
>> Pozdrawiam
>> Konrad Banachowicz
> Herman
>
>> 2012/11/30 Erwin Aertbelien <Erwin [dot] Aertbelien [..] ...>
>> What type of robot are you using? A typical 5-dof welding robot ?
>>
>> If it is a robot with its last 2 axes intersecting in 1 point, an
>> analytical solution to
>> the inverse position kinematics exists:
>>
>> * Such a solution is prefered above numerical solution.
>> * "Pieper's solution" to the inverse kinematics of a 3-2-1 robot can be
>> an inspiration (cfr. any textbook on robotics):
>> you split up the inverse kinematics problem into a part involving the 3
>> first joints and a part involving the
>> last 3 joints. For that last parts the KDL routines for euler angles or
>> rpy angles could be useful.
>>
>> Best regards,
>> Erwin.
>>
>>
>> On 11/30/2012 08:55 PM, Aaron O'Toole <airuno2L [..] ...> wrote:
>> > Hello all,
>> >
>> > Quick question: I have a 5 dof arm I need to do inverse position
>> > kinematics with (it doens't have a yaw joint). I've read through
>> > messages in the mailing list about this but am still having some
>> > trouble.
>> >
>> > This conversation has been of help:
>> > http://lists.mech.kuleuven.be/pipermail/orocos-users/2011-March/003255.html
>> >
>> > But I'm not sure how to follow through. I have:
>> >
>> > ChainFkSolverPos_recursive fksolver(chain);//Forward position solver
>> > ChainIkSolverVel_wdls iksolver1v(chain);//Inverse velocity solver
>> >
>> > Eigen::VectorXd weight_ts(6);
>> > weight_ts[1]=weight_ts[2]=weight_ts[3]=weight_ts[3]=weight_ts[4]=1.0;//X,Y,Z,roll
>> > pitch
>> > weight_ts[5]=0.0;//yaw
>> > iksolver1v.setWeightTS (weight_ts.asDiagonal());
>> >
>> > ChainIkSolverPos_NR iksolver1(chain,fksolver,iksolver1v,1000,1e-3);
>> > JntArray q(chain.getNrOfJoints());
>> > JntArray q_init(chain.getNrOfJoints());
>> >
>> > Frame F_dest=Frame(Rotation::RPY(-1.07, 0.94, 1.0), Vector(0.58,
>> > -0.38, -0.85));
>> > int ret = iksolver1.CartToJnt(q_init,F_dest,q);
>> >
>> >
>> > If I plug in a frame that I know my robot can acheive (including the
>> > yaw) the ik solver works, but if I just change the yaw value in F_dest
>> > it will fail and return -3, which tells me its not ignoring the yaw.
>> > Is there something else I need to do? Ruben mentions "adapt the
>> > ChainFkSolverPos_recursive to also take a TaskSpace Weight into
>> > account". Is this needed? Is it already implemented somewhere and I'm
>> > missing it? If I need to do implement it myself, can someone point me
>> > in the right direction?
>> >
>> > thanks,
>> > Aaron
>> >
>> >
>>
>> --
>> Orocos-Users mailing list
>> Orocos-Users [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>
>>
>>
>>
> --
> KU Leuven, Mechanical Engineering, Robotics Research Group
> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> Vice-President Research euRobotics <http://www.eu-robotics.net>
> Open RObot COntrol Software <http://www.orocos.org>
> Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>

Help with 5 DOF arm

On Sun, 2 Dec 2012, Erwin Aertbelien wrote:

> On 12/02/2012 11:59 AM, Herman Bruyninckx wrote:
>> On Sat, 1 Dec 2012, Konrad Banachowicz wrote:
>>
>>> I would suggest using
>>> http://openrave.org/docs/latest_stable/openravepy/ikfast/ to generate
>>> closed-form ik and using numerical ik only if ikfast can't solve your type
>>> of kinematic chain.
>> Which is almost always the case. Because real robotics systems do a lot
>> more than just computing inverse/forward position kinematics: they add
>> control, optimization, dynamics, estimation, joint limit avoidance,
>> actuator limit monitoring,... into the computations of the kinematics. And
>> there are no closed form solutions for those.
>>
>> However, KDL has very efficient closed form solutions too, for the
>> traditional 6-DOF industrial robot kinematics.
> Not any more,
> several years ago, Ruben removed these routines from KDL.

It would be easy to add them again, I imagine.

Maybe the problem was that they were an heritage from the good old C times,
and hence not so compliant to the modern C++ KDL style?

Anyway, although they were very efficiently coded, there would not fill a
very good need anymore, since, as I mentioned in my earlier post, just
doing FK/IK is a thing of the past. Unfortunately, many newcomers to
robotics seem to think otherwise, in their act of rediscovering the state
of the art and practice, slowly, very slowly...

>>> Pozdrawiam
>>> Konrad Banachowicz

Herman

>>> 2012/11/30 Erwin Aertbelien <Erwin [dot] Aertbelien [..] ...>
>>> What type of robot are you using? A typical 5-dof welding robot ?
>>>
>>> If it is a robot with its last 2 axes intersecting in 1 point, an
>>> analytical solution to
>>> the inverse position kinematics exists:
>>>
>>> * Such a solution is prefered above numerical solution.
>>> * "Pieper's solution" to the inverse kinematics of a 3-2-1 robot
>>> can be
>>> an inspiration (cfr. any textbook on robotics):
>>> you split up the inverse kinematics problem into a part involving
>>> the 3
>>> first joints and a part involving the
>>> last 3 joints. For that last parts the KDL routines for euler
>>> angles or
>>> rpy angles could be useful.
>>>
>>> Best regards,
>>> Erwin.
>>>
>>>
>>> On 11/30/2012 08:55 PM, Aaron O'Toole <airuno2L [..] ...> wrote:
>>> > Hello all,
>>> >
>>> > Quick question: I have a 5 dof arm I need to do inverse position
>>> > kinematics with (it doens't have a yaw joint). I've read through
>>> > messages in the mailing list about this but am still having some
>>> > trouble.
>>> >
>>> > This conversation has been of help:
>>> >
>>> http://lists.mech.kuleuven.be/pipermail/orocos-users/2011-March/003255.html
>>> >
>>> > But I'm not sure how to follow through. I have:
>>> >
>>> > ChainFkSolverPos_recursive fksolver(chain);//Forward position
>>> solver
>>> > ChainIkSolverVel_wdls iksolver1v(chain);//Inverse velocity solver
>>> >
>>> > Eigen::VectorXd weight_ts(6);
>>> >
>>> weight_ts[1]=weight_ts[2]=weight_ts[3]=weight_ts[3]=weight_ts[4]=1.0;//X,Y,Z,roll
>>> > pitch
>>> > weight_ts[5]=0.0;//yaw
>>> > iksolver1v.setWeightTS (weight_ts.asDiagonal());
>>> >
>>> > ChainIkSolverPos_NR
>>> iksolver1(chain,fksolver,iksolver1v,1000,1e-3);
>>> > JntArray q(chain.getNrOfJoints());
>>> > JntArray q_init(chain.getNrOfJoints());
>>> >
>>> > Frame F_dest=Frame(Rotation::RPY(-1.07, 0.94, 1.0), Vector(0.58,
>>> > -0.38, -0.85));
>>> > int ret = iksolver1.CartToJnt(q_init,F_dest,q);
>>> >
>>> >
>>> > If I plug in a frame that I know my robot can acheive (including
>>> the
>>> > yaw) the ik solver works, but if I just change the yaw value in
>>> F_dest
>>> > it will fail and return -3, which tells me its not ignoring the
>>> yaw.
>>> > Is there something else I need to do? Ruben mentions "adapt the
>>> > ChainFkSolverPos_recursive to also take a TaskSpace Weight into
>>> > account". Is this needed? Is it already implemented somewhere and
>>> I'm
>>> > missing it? If I need to do implement it myself, can someone
>>> point me
>>> > in the right direction?
>>> >
>>> > thanks,
>>> > Aaron
>>> >
>>> >
>>>
>>> --
>>> Orocos-Users mailing list
>>> Orocos-Users [..] ...
>>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>>
>>>
>>>
>>>
>> --
>> KU Leuven, Mechanical Engineering, Robotics Research Group
>> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
>> Vice-President Research euRobotics <http://www.eu-robotics.net>
>> Open RObot COntrol Software <http://www.orocos.org>
>> Associate Editor JOSER <http://www.joser.org>, IJRR
>> <http://www.ijrr.org>
>
>

--
KU Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
Vice-President Research euRobotics <http://www.eu-robotics.net>
Open RObot COntrol Software <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>

Help with 5 DOF arm

just
doing FK/IK is a thing of the past. Unfortunately, many newcomers to
robotics seem to think otherwise, in their act of rediscovering the state
of the art and practice, slowly, very slowly...

Just doing FK/IK might not suffice for your applications, but it does for
the one I'm currently working on (tele-operation). I simply need a function
that takes in cartesian coordinates and outputs joint angles. How the arm
gets from point A to B does not matter in my application. Assuming I'm a
novice in robotics because I'm asking for help on a user mailing list is a
bit foolish. I'm just new to KDL and trying to learn more about it...thanks
for the warm welcome though.

On Sun, Dec 2, 2012 at 6:24 AM, Herman Bruyninckx <
Herman [dot] Bruyninckx [..] ...> wrote:

> On Sun, 2 Dec 2012, Erwin Aertbelien wrote:
>
> > On 12/02/2012 11:59 AM, Herman Bruyninckx wrote:
> >> On Sat, 1 Dec 2012, Konrad Banachowicz wrote:
> >>
> >>> I would suggest using
> >>> http://openrave.org/docs/latest_stable/openravepy/ikfast/ to generate
> >>> closed-form ik and using numerical ik only if ikfast can't solve your
> type
> >>> of kinematic chain.
> >> Which is almost always the case. Because real robotics systems do a lot
> >> more than just computing inverse/forward position kinematics: they add
> >> control, optimization, dynamics, estimation, joint limit avoidance,
> >> actuator limit monitoring,... into the computations of the kinematics.
> And
> >> there are no closed form solutions for those.
> >>
> >> However, KDL has very efficient closed form solutions too, for the
> >> traditional 6-DOF industrial robot kinematics.
> > Not any more,
> > several years ago, Ruben removed these routines from KDL.
>
> It would be easy to add them again, I imagine.
>
> Maybe the problem was that they were an heritage from the good old C times,
> and hence not so compliant to the modern C++ KDL style?
>
> Anyway, although they were very efficiently coded, there would not fill a
> very good need anymore, since, as I mentioned in my earlier post, just
> doing FK/IK is a thing of the past. Unfortunately, many newcomers to
> robotics seem to think otherwise, in their act of rediscovering the state
> of the art and practice, slowly, very slowly...
>
> >>> Pozdrawiam
> >>> Konrad Banachowicz
>
> Herman
>
> >>> 2012/11/30 Erwin Aertbelien <Erwin [dot] Aertbelien [..] ...>
> >>> What type of robot are you using? A typical 5-dof welding robot
> ?
> >>>
> >>> If it is a robot with its last 2 axes intersecting in 1 point,
> an
> >>> analytical solution to
> >>> the inverse position kinematics exists:
> >>>
> >>> * Such a solution is prefered above numerical solution.
> >>> * "Pieper's solution" to the inverse kinematics of a 3-2-1 robot
> >>> can be
> >>> an inspiration (cfr. any textbook on robotics):
> >>> you split up the inverse kinematics problem into a part
> involving
> >>> the 3
> >>> first joints and a part involving the
> >>> last 3 joints. For that last parts the KDL routines for euler
> >>> angles or
> >>> rpy angles could be useful.
> >>>
> >>> Best regards,
> >>> Erwin.
> >>>
> >>>
> >>> On 11/30/2012 08:55 PM, Aaron O'Toole <airuno2L [..] ...>
> wrote:
> >>> > Hello all,
> >>> >
> >>> > Quick question: I have a 5 dof arm I need to do inverse
> position
> >>> > kinematics with (it doens't have a yaw joint). I've read
> through
> >>> > messages in the mailing list about this but am still having
> some
> >>> > trouble.
> >>> >
> >>> > This conversation has been of help:
> >>> >
> >>>
> http://lists.mech.kuleuven.be/pipermail/orocos-users/2011-March/003255.html
> >>> >
> >>> > But I'm not sure how to follow through. I have:
> >>> >
> >>> > ChainFkSolverPos_recursive fksolver(chain);//Forward position
> >>> solver
> >>> > ChainIkSolverVel_wdls iksolver1v(chain);//Inverse velocity
> solver
> >>> >
> >>> > Eigen::VectorXd weight_ts(6);
> >>> >
> >>>
> weight_ts[1]=weight_ts[2]=weight_ts[3]=weight_ts[3]=weight_ts[4]=1.0;//X,Y,Z,roll
> >>> > pitch
> >>> > weight_ts[5]=0.0;//yaw
> >>> > iksolver1v.setWeightTS (weight_ts.asDiagonal());
> >>> >
> >>> > ChainIkSolverPos_NR
> >>> iksolver1(chain,fksolver,iksolver1v,1000,1e-3);
> >>> > JntArray q(chain.getNrOfJoints());
> >>> > JntArray q_init(chain.getNrOfJoints());
> >>> >
> >>> > Frame F_dest=Frame(Rotation::RPY(-1.07, 0.94, 1.0),
> Vector(0.58,
> >>> > -0.38, -0.85));
> >>> > int ret = iksolver1.CartToJnt(q_init,F_dest,q);
> >>> >
> >>> >
> >>> > If I plug in a frame that I know my robot can acheive
> (including
> >>> the
> >>> > yaw) the ik solver works, but if I just change the yaw value
> in
> >>> F_dest
> >>> > it will fail and return -3, which tells me its not ignoring
> the
> >>> yaw.
> >>> > Is there something else I need to do? Ruben mentions "adapt
> the
> >>> > ChainFkSolverPos_recursive to also take a TaskSpace Weight
> into
> >>> > account". Is this needed? Is it already implemented somewhere
> and
> >>> I'm
> >>> > missing it? If I need to do implement it myself, can someone
> >>> point me
> >>> > in the right direction?
> >>> >
> >>> > thanks,
> >>> > Aaron
> >>> >
> >>> >
> >>>
> >>> --
> >>> Orocos-Users mailing list
> >>> Orocos-Users [..] ...
> >>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
> >>>
> >>>
> >>>
> >>>
> >> --
> >> KU Leuven, Mechanical Engineering, Robotics Research Group
> >> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> >> Vice-President Research euRobotics <http://www.eu-robotics.net>
> >> Open RObot COntrol Software <http://www.orocos.org>
> >> Associate Editor JOSER <http://www.joser.org>, IJRR
> >> <http://www.ijrr.org>
> >
> >
>
> --
> KU Leuven, Mechanical Engineering, Robotics Research Group
> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> Vice-President Research euRobotics <http://www.eu-robotics.net>
> Open RObot COntrol Software <http://www.orocos.org>
> Associate Editor JOSER <http://www.joser.org>, IJRR <
> http://www.ijrr.org>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

Help with 5 DOF arm

On Mon, 3 Dec 2012, Aaron O'Toole <airuno2L [..] ...> wrote:

> just
> doing FK/IK is a thing of the past. Unfortunately, many newcomers to
> robotics seem to think otherwise, in their act of rediscovering the state
> of the art and practice, slowly, very slowly...
>
> Just doing FK/IK might not suffice for your applications, but it does for the one I'm currently
> working on (tele-operation). I simply need a function that takes in cartesian coordinates and
> outputs joint angles. How the arm gets from point A to B does not matter in my application.
> Assuming I'm a novice in robotics because I'm asking for help on a user mailing list is a bit
> foolish. I'm just new to KDL and trying to learn more about it...thanks for the warm welcome
> though. 

I'm sorry if I offended someone's feelings! (If that is what I read between
the lines.) But even if you are not interested how the arm gets from A to
B, it _has_ to get from A to B, hence your application will be doing more
than "just IK", since the interpolation of the path is something that has
to be done. So, it makes sense to look for "solvers" that include that
interpolation.

Herman

> On Sun, Dec 2, 2012 at 6:24 AM, Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...> wrote:
> On Sun, 2 Dec 2012, Erwin Aertbelien wrote:
>
> > On 12/02/2012 11:59 AM, Herman Bruyninckx wrote:
> >> On Sat, 1 Dec 2012, Konrad Banachowicz wrote:
> >>
> >>> I would suggest using
> >>> http://openrave.org/docs/latest_stable/openravepy/ikfast/ to generate
> >>> closed-form ik and using numerical ik only if ikfast can't solve your type
> >>> of kinematic chain.
> >> Which is almost always the case. Because real robotics systems do a lot
> >> more than just computing inverse/forward position kinematics: they add
> >> control, optimization, dynamics, estimation, joint limit avoidance,
> >> actuator limit monitoring,... into the computations of the kinematics. And
> >> there are no closed form solutions for those.
> >>
> >> However, KDL has very efficient closed form solutions too, for the
> >> traditional 6-DOF industrial robot kinematics.
> > Not any more,
> > several years ago, Ruben removed these routines from KDL.
>
> It would be easy to add them again, I imagine.
>
> Maybe the problem was that they were an heritage from the good old C times,
> and hence not so compliant to the modern C++ KDL style?
>
> Anyway, although they were very efficiently coded, there would not fill a
> very good need anymore, since, as I mentioned in my earlier post, just
> doing FK/IK is a thing of the past. Unfortunately, many newcomers to
> robotics seem to think otherwise, in their act of rediscovering the state
> of the art and practice, slowly, very slowly...
>
> >>> Pozdrawiam
> >>> Konrad Banachowicz
>
> Herman
>
> >>> 2012/11/30 Erwin Aertbelien <Erwin [dot] Aertbelien [..] ...>
> >>>        What type of robot are you using? A typical 5-dof welding robot ?
> >>>
> >>>        If it is a robot with its last 2 axes intersecting in 1 point, an
> >>>        analytical solution to
> >>>        the inverse position kinematics exists:
> >>>
> >>>        *  Such a solution is prefered above numerical solution.
> >>>        * "Pieper's solution" to the inverse kinematics of a 3-2-1 robot
> >>> can be
> >>>        an inspiration (cfr. any textbook on robotics):
> >>>        you split up the inverse kinematics problem into a part involving
> >>> the 3
> >>>        first joints and a part involving the
> >>>        last 3 joints.  For that last parts the KDL routines for euler
> >>> angles or
> >>>        rpy angles could be useful.
> >>>
> >>>        Best regards,
> >>>        Erwin.
> >>>
> >>>
> >>>        On 11/30/2012 08:55 PM, Aaron O'Toole <airuno2L [..] ...> wrote:
> >>>        > Hello all,
> >>>        >
> >>>        > Quick question: I have a 5 dof arm I need to do inverse position
> >>>        > kinematics with (it doens't have a yaw joint). I've read through
> >>>        > messages in the mailing list about this but am still having some
> >>>        > trouble.
> >>>        >
> >>>        > This conversation has been of help:
> >>>        >
> >>> http://lists.mech.kuleuven.be/pipermail/orocos-users/2011-March/003255.html
> >>>        >
> >>>        > But I'm not sure how to follow through. I have:
> >>>        >
> >>>        > ChainFkSolverPos_recursive fksolver(chain);//Forward position
> >>> solver
> >>>        > ChainIkSolverVel_wdls iksolver1v(chain);//Inverse velocity solver
> >>>        >
> >>>        > Eigen::VectorXd weight_ts(6);
> >>>        >
> >>> weight_ts[1]=weight_ts[2]=weight_ts[3]=weight_ts[3]=weight_ts[4]=1.0;//X,Y,Z,roll
> >>>        > pitch
> >>>        > weight_ts[5]=0.0;//yaw
> >>>        > iksolver1v.setWeightTS (weight_ts.asDiagonal());
> >>>        >
> >>>        > ChainIkSolverPos_NR
> >>> iksolver1(chain,fksolver,iksolver1v,1000,1e-3);
> >>>        > JntArray q(chain.getNrOfJoints());
> >>>        > JntArray q_init(chain.getNrOfJoints());
> >>>        >
> >>>        > Frame F_dest=Frame(Rotation::RPY(-1.07, 0.94, 1.0), Vector(0.58,
> >>>        > -0.38, -0.85));
> >>>        > int ret = iksolver1.CartToJnt(q_init,F_dest,q);
> >>>        >
> >>>        >
> >>>        > If I plug in a frame that I know my robot can acheive (including
> >>> the
> >>>        > yaw) the ik solver works, but if I just change the yaw value in
> >>> F_dest
> >>>        > it will fail and return -3, which tells me its not ignoring the
> >>> yaw.
> >>>        > Is there something else I need to do? Ruben mentions "adapt the
> >>>        > ChainFkSolverPos_recursive to also take a TaskSpace Weight into
> >>>        > account". Is this needed? Is it already implemented somewhere and
> >>> I'm
> >>>        > missing it? If I need to do implement it myself, can someone
> >>> point me
> >>>        > in the right direction?
> >>>        >
> >>>        > thanks,
> >>>        > Aaron
> >>>        >
> >>>        >
> >>>
> >>>        --
> >>> Orocos-Users mailing list
> >>> Orocos-Users [..] ...
> >>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
> >>>
> >>>
> >>>
> >>>
> >> --
> >>     KU Leuven, Mechanical Engineering, Robotics Research Group
> >>       <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> >>     Vice-President Research euRobotics <http://www.eu-robotics.net>
> >>     Open RObot COntrol Software <http://www.orocos.org>
> >>     Associate Editor JOSER <http://www.joser.org>, IJRR
> >> <http://www.ijrr.org>
> >
> >
>
> --
>    KU Leuven, Mechanical Engineering, Robotics Research Group
>      <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
>    Vice-President Research euRobotics <http://www.eu-robotics.net>
>    Open RObot COntrol Software <http://www.orocos.org>
>    Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>
>
>
> --
> - Aaron O'Toole
>
>

--
KU Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
Vice-President Research euRobotics <http://www.eu-robotics.net>
Open RObot COntrol Software <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>

Help with 5 DOF arm

On 12/02/2012 12:24 PM, Herman Bruyninckx wrote:
> On Sun, 2 Dec 2012, Erwin Aertbelien wrote:
>
>> On 12/02/2012 11:59 AM, Herman Bruyninckx wrote:
>>> On Sat, 1 Dec 2012, Konrad Banachowicz wrote:
>>>
>>>> I would suggest using
>>>> http://openrave.org/docs/latest_stable/openravepy/ikfast/ to generate
>>>> closed-form ik and using numerical ik only if ikfast can't solve
>>>> your type of kinematic chain.
>>> Which is almost always the case. Because real robotics systems do a lot
>>> more than just computing inverse/forward position kinematics: they add
>>> control, optimization, dynamics, estimation, joint limit avoidance,
>>> actuator limit monitoring,... into the computations of the
>>> kinematics. And
>>> there are no closed form solutions for those.
>>>
>>> However, KDL has very efficient closed form solutions too, for the
>>> traditional 6-DOF industrial robot kinematics.
>> Not any more,
>> several years ago, Ruben removed these routines from KDL.
>
> It would be easy to add them again, I imagine.
>
> Maybe the problem was that they were an heritage from the good old C
> times,
> and hence not so compliant to the modern C++ KDL style?
>
> Anyway, although they were very efficiently coded, there would not fill a
> very good need anymore, since, as I mentioned in my earlier post, just
> doing FK/IK is a thing of the past. Unfortunately, many newcomers to
> of the art and practice, slowly, very slowly...
Some add. comments:
- only if you have a robot where the inv. pos. can be expressed
analytically (typically, an old-style industrial robot).
- do not use closed form inv. pos. kin. if you have to evaluate it
at each sample time. A much better (and general)
solution for this is to integrate inv. vel. kin. Closed form
solutions are good to compute an initial position of the robot or
to compute the target position of a joint space motion.
- the closed form solution has the advantage that it describes and
can very easily handle
different configurations of the robot ( configurations: different
solutions to the inv. pos. problem for
the same end effector pose).
- industrial robots were typically build with the last axes
intersecting, such that a closed form solution
exists. This is however introducing complexity in the mechanical
hardware to solve a software problem !
Robot companies such as Universal Robots are abandoning these
principles, they do not want to use a
closed form inv. pos. kin. solution (or at least, I do not think
they have a closed form solution),
and are therefore able to construct cheaper robots.

>
>>>> Pozdrawiam
>>>> Konrad Banachowicz
>
> Herman
>
>>>> 2012/11/30 Erwin Aertbelien <Erwin [dot] Aertbelien [..] ...>
>>>> What type of robot are you using? A typical 5-dof welding
>>>> robot ?
>>>>
>>>> If it is a robot with its last 2 axes intersecting in 1
>>>> point, an
>>>> analytical solution to
>>>> the inverse position kinematics exists:
>>>>
>>>> * Such a solution is prefered above numerical solution.
>>>> * "Pieper's solution" to the inverse kinematics of a 3-2-1
>>>> robot can be
>>>> an inspiration (cfr. any textbook on robotics):
>>>> you split up the inverse kinematics problem into a part
>>>> involving the 3
>>>> first joints and a part involving the
>>>> last 3 joints. For that last parts the KDL routines for
>>>> euler angles or
>>>> rpy angles could be useful.
>>>>
>>>> Best regards,
>>>> Erwin.
>>>>
>>>>
>>>> On 11/30/2012 08:55 PM, Aaron O'Toole <airuno2L [..] ...>
>>>> wrote:
>>>> > Hello all,
>>>> >
>>>> > Quick question: I have a 5 dof arm I need to do inverse
>>>> position
>>>> > kinematics with (it doens't have a yaw joint). I've read
>>>> through
>>>> > messages in the mailing list about this but am still
>>>> having some
>>>> > trouble.
>>>> >
>>>> > This conversation has been of help:
>>>> >
>>>> http://lists.mech.kuleuven.be/pipermail/orocos-users/2011-March/003255.html
>>>> >
>>>> > But I'm not sure how to follow through. I have:
>>>> >
>>>> > ChainFkSolverPos_recursive fksolver(chain);//Forward
>>>> position solver
>>>> > ChainIkSolverVel_wdls iksolver1v(chain);//Inverse velocity
>>>> solver
>>>> >
>>>> > Eigen::VectorXd weight_ts(6);
>>>> >
>>>> weight_ts[1]=weight_ts[2]=weight_ts[3]=weight_ts[3]=weight_ts[4]=1.0;//X,Y,Z,roll
>>>> > pitch
>>>> > weight_ts[5]=0.0;//yaw
>>>> > iksolver1v.setWeightTS (weight_ts.asDiagonal());
>>>> >
>>>> > ChainIkSolverPos_NR
>>>> iksolver1(chain,fksolver,iksolver1v,1000,1e-3);
>>>> > JntArray q(chain.getNrOfJoints());
>>>> > JntArray q_init(chain.getNrOfJoints());
>>>> >
>>>> > Frame F_dest=Frame(Rotation::RPY(-1.07, 0.94, 1.0),
>>>> Vector(0.58,
>>>> > -0.38, -0.85));
>>>> > int ret = iksolver1.CartToJnt(q_init,F_dest,q);
>>>> >
>>>> >
>>>> > If I plug in a frame that I know my robot can acheive
>>>> (including the
>>>> > yaw) the ik solver works, but if I just change the yaw
>>>> value in F_dest
>>>> > it will fail and return -3, which tells me its not
>>>> ignoring the yaw.
>>>> > Is there something else I need to do? Ruben mentions
>>>> "adapt the
>>>> > ChainFkSolverPos_recursive to also take a TaskSpace Weight
>>>> into
>>>> > account". Is this needed? Is it already implemented
>>>> somewhere and I'm
>>>> > missing it? If I need to do implement it myself, can
>>>> someone point me
>>>> > in the right direction?
>>>> >
>>>> > thanks,
>>>> > Aaron
>>>> >
>>>> >
>>>>
>>>> --
>>>> Orocos-Users mailing list
>>>> Orocos-Users [..] ...
>>>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>>>
>>>>
>>>>
>>>>
>>> --
>>> KU Leuven, Mechanical Engineering, Robotics Research Group
>>> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
>>> Vice-President Research euRobotics <http://www.eu-robotics.net>
>>> Open RObot COntrol Software <http://www.orocos.org>
>>> Associate Editor JOSER <http://www.joser.org>, IJRR
>>> <http://www.ijrr.org>
>>
>>
>

Help with 5 DOF arm

opps, didn't hit reply all:

The key to my problem is that I don't have just one kinematic chain that I
want to solve for, I'm building an application that a developer can feed a
kinematic chain, and the kinematics (including selection of a suitable
solver) happens behind the scene. The chain can be anywhere from 4 to 7
dof...my understanding is that this is the type of thing KDL is suited for.

I'll certainly look into ikfast, but I think it is desirable for me to only
use KDL. I realize the benefits of closed-formed solutions (speed), but the
benefit of numerical solutions (being able to solve for a greater variety
of kinematic chains) outweighs it in my case. Also, in my application, the
solver can take as long as one second and no one would notice.

Thanks,
Aaron

On Sat, Dec 1, 2012 at 6:52 AM, Konrad Banachowicz <konradb3 [..] ...>wrote:

> I would suggest using
> http://openrave.org/docs/latest_stable/openravepy/ikfast/ to generate
> closed-form ik and using numerical ik only if ikfast can't solve your type
> of kinematic chain.
>
> Pozdrawiam
> Konrad Banachowicz
>
>
> 2012/11/30 Erwin Aertbelien <Erwin [dot] Aertbelien [..] ...>
>
>> What type of robot are you using? A typical 5-dof welding robot ?
>>
>> If it is a robot with its last 2 axes intersecting in 1 point, an
>> analytical solution to
>> the inverse position kinematics exists:
>>
>> * Such a solution is prefered above numerical solution.
>> * "Pieper's solution" to the inverse kinematics of a 3-2-1 robot can be
>> an inspiration (cfr. any textbook on robotics):
>> you split up the inverse kinematics problem into a part involving the 3
>> first joints and a part involving the
>> last 3 joints. For that last parts the KDL routines for euler angles or
>> rpy angles could be useful.
>>
>> Best regards,
>> Erwin.
>>
>>
>> On 11/30/2012 08:55 PM, Aaron O'Toole <airuno2L [..] ...> wrote:
>> > Hello all,
>> >
>> > Quick question: I have a 5 dof arm I need to do inverse position
>> > kinematics with (it doens't have a yaw joint). I've read through
>> > messages in the mailing list about this but am still having some
>> > trouble.
>> >
>> > This conversation has been of help:
>> >
>> http://lists.mech.kuleuven.be/pipermail/orocos-users/2011-March/003255.html
>> >
>> > But I'm not sure how to follow through. I have:
>> >
>> > ChainFkSolverPos_recursive fksolver(chain);//Forward position solver
>> > ChainIkSolverVel_wdls iksolver1v(chain);//Inverse velocity solver
>> >
>> > Eigen::VectorXd weight_ts(6);
>> >
>> weight_ts[1]=weight_ts[2]=weight_ts[3]=weight_ts[3]=weight_ts[4]=1.0;//X,Y,Z,roll
>> > pitch
>> > weight_ts[5]=0.0;//yaw
>> > iksolver1v.setWeightTS (weight_ts.asDiagonal());
>> >
>> > ChainIkSolverPos_NR iksolver1(chain,fksolver,iksolver1v,1000,1e-3);
>> > JntArray q(chain.getNrOfJoints());
>> > JntArray q_init(chain.getNrOfJoints());
>> >
>> > Frame F_dest=Frame(Rotation::RPY(-1.07, 0.94, 1.0), Vector(0.58,
>> > -0.38, -0.85));
>> > int ret = iksolver1.CartToJnt(q_init,F_dest,q);
>> >
>> >
>> > If I plug in a frame that I know my robot can acheive (including the
>> > yaw) the ik solver works, but if I just change the yaw value in F_dest
>> > it will fail and return -3, which tells me its not ignoring the yaw.
>> > Is there something else I need to do? Ruben mentions "adapt the
>> > ChainFkSolverPos_recursive to also take a TaskSpace Weight into
>> > account". Is this needed? Is it already implemented somewhere and I'm
>> > missing it? If I need to do implement it myself, can someone point me
>> > in the right direction?
>> >
>> > thanks,
>> > Aaron
>> >
>> >
>>
>> --
>> Orocos-Users mailing list
>> Orocos-Users [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>
>
>