IK with KDL

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

IK with KDL

Jeroen Willems
Hi,

I have a question regarding the inverse kinematics using KDL.

I would like to use carttojnt of the inverse kinematics solver.
The problem is I have to use a destination frame as input.
I'm using something similar to a elbow manipulator so you can imagine I only want a reference position.
The arm only can have 2 poses to a reference position, to get the rotational part of the frame I actually have to get the joint positions to calculate it (correct me if I'm wrong).

So
1. Am I right?
2. Could I use KDL to compute the IK or should I use an analytic solution?

Thanks in advance.

Jeroen

http://www1bpt.bridgeport.edu/~risc/html/proj/damir/img00015.gif

_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: IK with KDL

Herman Bruyninckx
On Tue, 9 Nov 2010, Jeroen Willems wrote:

> I have a question regarding the inverse kinematics using KDL.
>
> I would like to use carttojnt of the inverse kinematics solver.
> The problem is I have to use a destination frame as input.
> I'm using something similar to a elbow manipulator so you can imagine I only want a reference position.
> The arm only can have 2 poses to a reference position, to get the rotational part of the frame I actually have to get the joint positions to calculate it (correct me if I'm wrong).
>
> So
> 1. Am I right?
> 2. Could I use KDL to compute the IK or should I use an analytic solution?

The major issue with your problem is that "IK" does not make too much sense
for a 2DOF system: when you don't take precautions the input frame will
never lie in the span of your 2DOF, so you will have make a "projection"
from the full 6D space onto your 2D subspace. KDL has algorithms to do
that, but they make choices about how to project that might not correspond
to your intuition. But that's inevitable.

So, please try to formulate exactly what kind of input you would like or
need to have.

Herman
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
dlu
Reply | Threaded
Open this post in threaded view
|

Re: IK with KDL

dlu
If you want an easy way to test if KDL can solve it, the
arm_kinematics package has some easy structure for that.
http://www.ros.org/wiki/arm_kinematics
-DL!!

On Tue, Nov 9, 2010 at 3:27 AM, Herman Bruyninckx
<[hidden email]> wrote:

> On Tue, 9 Nov 2010, Jeroen Willems wrote:
>
>> I have a question regarding the inverse kinematics using KDL.
>>
>> I would like to use carttojnt of the inverse kinematics solver.
>> The problem is I have to use a destination frame as input.
>> I'm using something similar to a elbow manipulator so you can imagine I only want a reference position.
>> The arm only can have 2 poses to a reference position, to get the rotational part of the frame I actually have to get the joint positions to calculate it (correct me if I'm wrong).
>>
>> So
>> 1. Am I right?
>> 2. Could I use KDL to compute the IK or should I use an analytic solution?
>
> The major issue with your problem is that "IK" does not make too much sense
> for a 2DOF system: when you don't take precautions the input frame will
> never lie in the span of your 2DOF, so you will have make a "projection"
> from the full 6D space onto your 2D subspace. KDL has algorithms to do
> that, but they make choices about how to project that might not correspond
> to your intuition. But that's inevitable.
>
> So, please try to formulate exactly what kind of input you would like or
> need to have.
>
> Herman
> _______________________________________________
> ros-users mailing list
> [hidden email]
> https://code.ros.org/mailman/listinfo/ros-users
>
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: IK with KDL

Jeroen Willems
In reply to this post by Jeroen Willems
On 2010-11-09 09:27, Herman Bruyninckx wrote:
> On Tue, 9 Nov 2010, Jeroen Willems wrote:
>
> > I have a question regarding the inverse kinematics using KDL.
> >
> > I would like to use carttojnt of the inverse kinematics solver.
> > The problem is I have to use a destination frame as input.
> > I'm using something similar to a elbow manipulator so you can imagine I only want a reference position.
> > The arm only can have 2 poses to a reference position, to get the rotational part of the frame I actually have to get the joint positions to calculate it (correct me if I'm wrong).
> >
> > So
> > 1. Am I right?
> > 2. Could I use KDL to compute the IK or should I use an analytic solution?
>
> The major issue with your problem is that "IK" does not make too much sense
> for a 2DOF system: when you don't take precautions the input frame will
> never lie in the span of your 2DOF, so you will have make a "projection"
> from the full 6D space onto your 2D subspace. KDL has algorithms to do
> that, but they make choices about how to project that might not correspond
> to your intuition. But that's inevitable.
>
> So, please try to formulate exactly what kind of input you would like or
> need to have.
>
> Herman
> _______________________________________________
> ros-users mailing list
> [hidden email]
> https://code.ros.org/mailman/listinfo/ros-users
>
>
Thanks for the response.

Okay to be more precise to give a better idea of what I'm doing.
I have an hexapod, so a torso with 6 legs consisting of 3 links (without torso) and 3 joints.
I want to be the tip/foot on an specific point (x,y,z) in respect to the torso (thorax) so I have to know the three joint positions to get there.

So preferable without giving a rotation. So I'm really curious how to obtain this or how to use a "projection".

Jeroen

_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: IK with KDL

Ruben Smits
On Thursday 11 November 2010 11:52:06 Jeroen Willems wrote:

> On 2010-11-09 09:27, Herman Bruyninckx wrote:
> > On Tue, 9 Nov 2010, Jeroen Willems wrote:
> > > I have a question regarding the inverse kinematics using KDL.
> > >
> > > I would like to use carttojnt of the inverse kinematics solver.
> > > The problem is I have to use a destination frame as input.
> > > I'm using something similar to a elbow manipulator so you can imagine I
> > > only want a reference position. The arm only can have 2 poses to a
> > > reference position, to get the rotational part of the frame I actually
> > > have to get the joint positions to calculate it (correct me if I'm
> > > wrong).
> > >
> > > So
> > > 1. Am I right?
> > > 2. Could I use KDL to compute the IK or should I use an analytic
> > > solution?
> >
> > The major issue with your problem is that "IK" does not make too much
> > sense for a 2DOF system: when you don't take precautions the input frame
> > will never lie in the span of your 2DOF, so you will have make a
> > "projection" from the full 6D space onto your 2D subspace. KDL has
> > algorithms to do that, but they make choices about how to project that
> > might not correspond to your intuition. But that's inevitable.
> >
> > So, please try to formulate exactly what kind of input you would like or
> > need to have.
> >
> > Herman
> > _______________________________________________
> > ros-users mailing list
> > [hidden email]<mailto:[hidden email]>
> > https://code.ros.org/mailman/listinfo/ros-users
>
> Thanks for the response.
>
> Okay to be more precise to give a better idea of what I'm doing.
> I have an hexapod, so a torso with 6 legs consisting of 3 links (without
> torso) and 3 joints. I want to be the tip/foot on an specific point
> (x,y,z) in respect to the torso (thorax) so I have to know the three joint
> positions to get there.
>
> So preferable without giving a rotation. So I'm really curious how to
> obtain this or how to use a "projection".

There is a inverse (CartToJnt) velocity solver in KDL that you can use to
disable (or weigth)  some of the degrees of freedom in the cartesian space:

http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/classKDL_1_1ChainIkSolverVel__wdls.html

You can use the setWeightTS function for this. Setting a diagonal value of
zero disables the joint, every other value neq 0 will be used as a weighting
value.

So if you want to disable the rotations, just set the last three diagonal
values to 0.

You can then use this solver in one of the inverse position solvers, but the
problem is that we do not have a solver yet that can take these weights into
account. But I do not think it should be to hard to figure that out yourself
when starting from the code of the iterative solver for the inverse position
kinematics:

http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/classKDL_1_1ChainIkSolverPos__NR.html


Ruben
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: IK with KDL

Ruben Smits
On Monday 15 November 2010 11:13:51 Ruben Smits wrote:

> On Thursday 11 November 2010 11:52:06 Jeroen Willems wrote:
> > On 2010-11-09 09:27, Herman Bruyninckx wrote:
> > > On Tue, 9 Nov 2010, Jeroen Willems wrote:
> > > > I have a question regarding the inverse kinematics using KDL.
> > > >
> > > > I would like to use carttojnt of the inverse kinematics solver.
> > > > The problem is I have to use a destination frame as input.
> > > > I'm using something similar to a elbow manipulator so you can imagine
> > > > I only want a reference position. The arm only can have 2 poses to a
> > > > reference position, to get the rotational part of the frame I
> > > > actually have to get the joint positions to calculate it (correct me
> > > > if I'm wrong).
> > > >
> > > > So
> > > > 1. Am I right?
> > > > 2. Could I use KDL to compute the IK or should I use an analytic
> > > > solution?
> > >
> > > The major issue with your problem is that "IK" does not make too much
> > > sense for a 2DOF system: when you don't take precautions the input
> > > frame will never lie in the span of your 2DOF, so you will have make a
> > > "projection" from the full 6D space onto your 2D subspace. KDL has
> > > algorithms to do that, but they make choices about how to project that
> > > might not correspond to your intuition. But that's inevitable.
> > >
> > > So, please try to formulate exactly what kind of input you would like
> > > or need to have.
> > >
> > > Herman
> > > _______________________________________________
> > > ros-users mailing list
> > > [hidden email]<mailto:[hidden email]>
> > > https://code.ros.org/mailman/listinfo/ros-users
> >
> > Thanks for the response.
> >
> > Okay to be more precise to give a better idea of what I'm doing.
> > I have an hexapod, so a torso with 6 legs consisting of 3 links (without
> > torso) and 3 joints. I want to be the tip/foot on an specific point
> > (x,y,z) in respect to the torso (thorax) so I have to know the three
> > joint positions to get there.
> >
> > So preferable without giving a rotation. So I'm really curious how to
> > obtain this or how to use a "projection".
>
> There is a inverse (CartToJnt) velocity solver in KDL that you can use to
> disable (or weigth)  some of the degrees of freedom in the cartesian space:
>
> http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/classK
> DL_1_1ChainIkSolverVel__wdls.html
>
> You can use the setWeightTS function for this. Setting a diagonal value of
> zero disables the joint, every other value neq 0 will be used as a
> weighting value.

This should have been: disables the degree of freedom (0-5)->(TX-Z,RX-Z)

R.

> So if you want to disable the rotations, just set the last three diagonal
> values to 0.
>
> You can then use this solver in one of the inverse position solvers, but
> the problem is that we do not have a solver yet that can take these
> weights into account. But I do not think it should be to hard to figure
> that out yourself when starting from the code of the iterative solver for
> the inverse position kinematics:
>
> http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/classK
> DL_1_1ChainIkSolverPos__NR.html
>
>
> Ruben
> _______________________________________________
> ros-users mailing list
> [hidden email]
> https://code.ros.org/mailman/listinfo/ros-users
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: IK with KDL

pibgeus
Hi Ruben and ROS community!

Our group is trying to use kdl IKs in a similar way as Herman says. We
are also interested in relaxing some of the destination frame
constraints. In our case we're only interested in the location of the
end-effector, not its orientation. We've been having a look to all
iksolvers (both position and velocity). As you said it seems easy to
figure out how solve this problem from the existing code. However we
are shuffling two alternatives:

1 - To implement a completely new iksolver_pos inspired in
ChainIkSolverPos_NR_JL and ChainIkSolverVel_wdls (mainly changing the
epsilon error check code taking into account the weights in the
iksolver_pos too)

2 - To implement the "the mysterious unimplemented and uncommented"
method: virtual int CartToJnt(const JntArray& q_init, const FrameVel&
v_in, JntArrayVel& q_out) of the ChainIkSolverVel_wdls. It's curious,
all of IkSolversVel have this method unimplemented. Why don't remove
it? :-)
We wonder if this method is supposed to solve the ikpos and ikvel
simultaneously. What is the right semantic of this method? Would such
implementation be cohesive with the class responsibilities?

This is our theory since the output of this method is a JntArrayVel
q_out object. We think that it could be implemented in this way:
q_out = [q_end, delta_q] / q_end = ik(get_pose(v_in)) ^ delta_q =
q_end - q_init.
(alternatively, another interpretation for delta_q could be: delta_q=
ik_vel(get_twist(v_in))

Suggestions? Corrections?
Thank you.


On Mon, Nov 15, 2010 at 11:34 AM, Ruben Smits
<[hidden email]> wrote:

>
> On Monday 15 November 2010 11:13:51 Ruben Smits wrote:
> > On Thursday 11 November 2010 11:52:06 Jeroen Willems wrote:
> > > On 2010-11-09 09:27, Herman Bruyninckx wrote:
> > > > On Tue, 9 Nov 2010, Jeroen Willems wrote:
> > > > > I have a question regarding the inverse kinematics using KDL.
> > > > >
> > > > > I would like to use carttojnt of the inverse kinematics solver.
> > > > > The problem is I have to use a destination frame as input.
> > > > > I'm using something similar to a elbow manipulator so you can imagine
> > > > > I only want a reference position. The arm only can have 2 poses to a
> > > > > reference position, to get the rotational part of the frame I
> > > > > actually have to get the joint positions to calculate it (correct me
> > > > > if I'm wrong).
> > > > >
> > > > > So
> > > > > 1. Am I right?
> > > > > 2. Could I use KDL to compute the IK or should I use an analytic
> > > > > solution?
> > > >
> > > > The major issue with your problem is that "IK" does not make too much
> > > > sense for a 2DOF system: when you don't take precautions the input
> > > > frame will never lie in the span of your 2DOF, so you will have make a
> > > > "projection" from the full 6D space onto your 2D subspace. KDL has
> > > > algorithms to do that, but they make choices about how to project that
> > > > might not correspond to your intuition. But that's inevitable.
> > > >
> > > > So, please try to formulate exactly what kind of input you would like
> > > > or need to have.
> > > >
> > > > Herman
> > > > _______________________________________________
> > > > ros-users mailing list
> > > > [hidden email]<mailto:[hidden email]>
> > > > https://code.ros.org/mailman/listinfo/ros-users
> > >
> > > Thanks for the response.
> > >
> > > Okay to be more precise to give a better idea of what I'm doing.
> > > I have an hexapod, so a torso with 6 legs consisting of 3 links (without
> > > torso) and 3 joints. I want to be the tip/foot on an specific point
> > > (x,y,z) in respect to the torso (thorax) so I have to know the three
> > > joint positions to get there.
> > >
> > > So preferable without giving a rotation. So I'm really curious how to
> > > obtain this or how to use a "projection".
> >
> > There is a inverse (CartToJnt) velocity solver in KDL that you can use to
> > disable (or weigth)  some of the degrees of freedom in the cartesian space:
> >
> > http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/classK
> > DL_1_1ChainIkSolverVel__wdls.html
> >
> > You can use the setWeightTS function for this. Setting a diagonal value of
> > zero disables the joint, every other value neq 0 will be used as a
> > weighting value.
>
> This should have been: disables the degree of freedom (0-5)->(TX-Z,RX-Z)
>
> R.
>
> > So if you want to disable the rotations, just set the last three diagonal
> > values to 0.
> >
> > You can then use this solver in one of the inverse position solvers, but
> > the problem is that we do not have a solver yet that can take these
> > weights into account. But I do not think it should be to hard to figure
> > that out yourself when starting from the code of the iterative solver for
> > the inverse position kinematics:
> >
> > http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/classK
> > DL_1_1ChainIkSolverPos__NR.html
> >
> >
> > Ruben
> > _______________________________________________
> > ros-users mailing list
> > [hidden email]
> > https://code.ros.org/mailman/listinfo/ros-users
> _______________________________________________
> ros-users mailing list
> [hidden email]
> https://code.ros.org/mailman/listinfo/ros-users



--
Pablo Iñigo Blasco.
Computer Architecture Department. Universidad de Sevilla (Spain)
http://es.linkedin.com/in/pibgeus | http://geus.wordpress.com
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: IK with KDL

Ruben Smits
On Sunday 05 December 2010 17:57:52 Pablo Iñigo Blasco wrote:

> Hi Ruben and ROS community!
>
> Our group is trying to use kdl IKs in a similar way as Herman says. We
> are also interested in relaxing some of the destination frame
> constraints. In our case we're only interested in the location of the
> end-effector, not its orientation. We've been having a look to all
> iksolvers (both position and velocity). As you said it seems easy to
> figure out how solve this problem from the existing code. However we
> are shuffling two alternatives:
>
> 1 - To implement a completely new iksolver_pos inspired in
> ChainIkSolverPos_NR_JL and ChainIkSolverVel_wdls (mainly changing the
> epsilon error check code taking into account the weights in the
> iksolver_pos too)
>
> 2 - To implement the "the mysterious unimplemented and uncommented"
> method: virtual int CartToJnt(const JntArray& q_init, const FrameVel&
> v_in, JntArrayVel& q_out) of the ChainIkSolverVel_wdls. It's curious,
> all of IkSolversVel have this method unimplemented. Why don't remove
> it? :-)
> We wonder if this method is supposed to solve the ikpos and ikvel
> simultaneously. What is the right semantic of this method?

That's exactly what it is supposed to do (according to the documentation of
the function: Calculate inverse position and velocity kinematics, from
cartesian position and velocity to joint positions and velocities)

I've introduced the function when I was playing with the idea that this was a
good thing. I'm not so sure anymore.

> Would such
> implementation be cohesive with the class responsibilities?

I think that might be the main problem. Because you loose the capability of
mixing different algorithms at the velocity and the position level.

> This is our theory since the output of this method is a JntArrayVel
> q_out object. We think that it could be implemented in this way:
> q_out = [q_end, delta_q] / q_end = ik(get_pose(v_in)) ^ delta_q =
> q_end - q_init.
> (alternatively, another interpretation for delta_q could be: delta_q=
> ik_vel(get_twist(v_in))
>
> Suggestions? Corrections?

After going through this I'm even more convinced the function should be
removed. There is no clean way to implement it generically.

Ruben

> Thank you.
>
>
> On Mon, Nov 15, 2010 at 11:34 AM, Ruben Smits
>
> <[hidden email]> wrote:
> > On Monday 15 November 2010 11:13:51 Ruben Smits wrote:
> > > On Thursday 11 November 2010 11:52:06 Jeroen Willems wrote:
> > > > On 2010-11-09 09:27, Herman Bruyninckx wrote:
> > > > > On Tue, 9 Nov 2010, Jeroen Willems wrote:
> > > > > > I have a question regarding the inverse kinematics using KDL.
> > > > > >
> > > > > > I would like to use carttojnt of the inverse kinematics solver.
> > > > > > The problem is I have to use a destination frame as input.
> > > > > > I'm using something similar to a elbow manipulator so you can
> > > > > > imagine I only want a reference position. The arm only can have
> > > > > > 2 poses to a reference position, to get the rotational part of
> > > > > > the frame I actually have to get the joint positions to
> > > > > > calculate it (correct me if I'm wrong).
> > > > > >
> > > > > > So
> > > > > > 1. Am I right?
> > > > > > 2. Could I use KDL to compute the IK or should I use an analytic
> > > > > > solution?
> > > > >
> > > > > The major issue with your problem is that "IK" does not make too
> > > > > much sense for a 2DOF system: when you don't take precautions the
> > > > > input frame will never lie in the span of your 2DOF, so you will
> > > > > have make a "projection" from the full 6D space onto your 2D
> > > > > subspace. KDL has algorithms to do that, but they make choices
> > > > > about how to project that might not correspond to your intuition.
> > > > > But that's inevitable.
> > > > >
> > > > > So, please try to formulate exactly what kind of input you would
> > > > > like or need to have.
> > > > >
> > > > > Herman
> > > > > _______________________________________________
> > > > > ros-users mailing list
> > > > > [hidden email]<mailto:[hidden email]>
> > > > > https://code.ros.org/mailman/listinfo/ros-users
> > > >
> > > > Thanks for the response.
> > > >
> > > > Okay to be more precise to give a better idea of what I'm doing.
> > > > I have an hexapod, so a torso with 6 legs consisting of 3 links
> > > > (without torso) and 3 joints. I want to be the tip/foot on an
> > > > specific point (x,y,z) in respect to the torso (thorax) so I have to
> > > > know the three joint positions to get there.
> > > >
> > > > So preferable without giving a rotation. So I'm really curious how to
> > > > obtain this or how to use a "projection".
> > >
> > > There is a inverse (CartToJnt) velocity solver in KDL that you can use
> > > to disable (or weigth)  some of the degrees of freedom in the
> > > cartesian space:
> > >
> > > http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/cl
> > > assK DL_1_1ChainIkSolverVel__wdls.html
> > >
> > > You can use the setWeightTS function for this. Setting a diagonal value
> > > of zero disables the joint, every other value neq 0 will be used as a
> > > weighting value.
> >
> > This should have been: disables the degree of freedom (0-5)->(TX-Z,RX-Z)
> >
> > R.
> >
> > > So if you want to disable the rotations, just set the last three
> > > diagonal values to 0.
> > >
> > > You can then use this solver in one of the inverse position solvers,
> > > but the problem is that we do not have a solver yet that can take
> > > these weights into account. But I do not think it should be to hard to
> > > figure that out yourself when starting from the code of the iterative
> > > solver for the inverse position kinematics:
> > >
> > > http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/cl
> > > assK DL_1_1ChainIkSolverPos__NR.html
> > >
> > >
> > > Ruben
> > > _______________________________________________
> > > ros-users mailing list
> > > [hidden email]
> > > https://code.ros.org/mailman/listinfo/ros-users
> >
> > _______________________________________________
> > ros-users mailing list
> > [hidden email]
> > https://code.ros.org/mailman/listinfo/ros-users
>
> --
> Pablo Iñigo Blasco.
> Computer Architecture Department. Universidad de Sevilla (Spain)
> http://es.linkedin.com/in/pibgeus | http://geus.wordpress.com
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: IK with KDL

Herman Bruyninckx
On Mon, 6 Dec 2010, Ruben Smits wrote:

> On Sunday 05 December 2010 17:57:52 Pablo Iñigo Blasco wrote:
>> Hi Ruben and ROS community!
>>
>> Our group is trying to use kdl IKs in a similar way as Herman says. We
>> are also interested in relaxing some of the destination frame
>> constraints. In our case we're only interested in the location of the
>> end-effector, not its orientation. We've been having a look to all
>> iksolvers (both position and velocity). As you said it seems easy to
>> figure out how solve this problem from the existing code. However we
>> are shuffling two alternatives:
>>
>> 1 - To implement a completely new iksolver_pos inspired in
>> ChainIkSolverPos_NR_JL and ChainIkSolverVel_wdls (mainly changing the
>> epsilon error check code taking into account the weights in the
>> iksolver_pos too)
>>
>> 2 - To implement the "the mysterious unimplemented and uncommented"
>> method: virtual int CartToJnt(const JntArray& q_init, const FrameVel&
>> v_in, JntArrayVel& q_out) of the ChainIkSolverVel_wdls. It's curious,
>> all of IkSolversVel have this method unimplemented. Why don't remove
>> it? :-)
>> We wonder if this method is supposed to solve the ikpos and ikvel
>> simultaneously. What is the right semantic of this method?
>
> That's exactly what it is supposed to do (according to the documentation of
> the function: Calculate inverse position and velocity kinematics, from
> cartesian position and velocity to joint positions and velocities)
Well, the naming of the parameters suggests something else: the IVK is
computed with the current joint positions as _inputs_, so the IPK need not
be solved anymore.

> I've introduced the function when I was playing with the idea that this was a
> good thing. I'm not so sure anymore.

There are use cases where this makes sense, since it is common to be able
to read the current joint positions.

Herman

>> Would such
>> implementation be cohesive with the class responsibilities?
>
> I think that might be the main problem. Because you loose the capability of
> mixing different algorithms at the velocity and the position level.
>
>> This is our theory since the output of this method is a JntArrayVel
>> q_out object. We think that it could be implemented in this way:
>> q_out = [q_end, delta_q] / q_end = ik(get_pose(v_in)) ^ delta_q =
>> q_end - q_init.
>> (alternatively, another interpretation for delta_q could be: delta_q=
>> ik_vel(get_twist(v_in))
>>
>> Suggestions? Corrections?
>
> After going through this I'm even more convinced the function should be
> removed. There is no clean way to implement it generically.

>
> Ruben
>
>> Thank you.
>>
>>
>> On Mon, Nov 15, 2010 at 11:34 AM, Ruben Smits
>>
>> <[hidden email]> wrote:
>>> On Monday 15 November 2010 11:13:51 Ruben Smits wrote:
>>>> On Thursday 11 November 2010 11:52:06 Jeroen Willems wrote:
>>>>> On 2010-11-09 09:27, Herman Bruyninckx wrote:
>>>>>> On Tue, 9 Nov 2010, Jeroen Willems wrote:
>>>>>>> I have a question regarding the inverse kinematics using KDL.
>>>>>>>
>>>>>>> I would like to use carttojnt of the inverse kinematics solver.
>>>>>>> The problem is I have to use a destination frame as input.
>>>>>>> I'm using something similar to a elbow manipulator so you can
>>>>>>> imagine I only want a reference position. The arm only can have
>>>>>>> 2 poses to a reference position, to get the rotational part of
>>>>>>> the frame I actually have to get the joint positions to
>>>>>>> calculate it (correct me if I'm wrong).
>>>>>>>
>>>>>>> So
>>>>>>> 1. Am I right?
>>>>>>> 2. Could I use KDL to compute the IK or should I use an analytic
>>>>>>> solution?
>>>>>>
>>>>>> The major issue with your problem is that "IK" does not make too
>>>>>> much sense for a 2DOF system: when you don't take precautions the
>>>>>> input frame will never lie in the span of your 2DOF, so you will
>>>>>> have make a "projection" from the full 6D space onto your 2D
>>>>>> subspace. KDL has algorithms to do that, but they make choices
>>>>>> about how to project that might not correspond to your intuition.
>>>>>> But that's inevitable.
>>>>>>
>>>>>> So, please try to formulate exactly what kind of input you would
>>>>>> like or need to have.
>>>>>>
>>>>>> Herman
>>>>>> _______________________________________________
>>>>>> ros-users mailing list
>>>>>> [hidden email]<mailto:[hidden email]>
>>>>>> https://code.ros.org/mailman/listinfo/ros-users
>>>>>
>>>>> Thanks for the response.
>>>>>
>>>>> Okay to be more precise to give a better idea of what I'm doing.
>>>>> I have an hexapod, so a torso with 6 legs consisting of 3 links
>>>>> (without torso) and 3 joints. I want to be the tip/foot on an
>>>>> specific point (x,y,z) in respect to the torso (thorax) so I have to
>>>>> know the three joint positions to get there.
>>>>>
>>>>> So preferable without giving a rotation. So I'm really curious how to
>>>>> obtain this or how to use a "projection".
>>>>
>>>> There is a inverse (CartToJnt) velocity solver in KDL that you can use
>>>> to disable (or weigth)  some of the degrees of freedom in the
>>>> cartesian space:
>>>>
>>>> http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/cl
>>>> assK DL_1_1ChainIkSolverVel__wdls.html
>>>>
>>>> You can use the setWeightTS function for this. Setting a diagonal value
>>>> of zero disables the joint, every other value neq 0 will be used as a
>>>> weighting value.
>>>
>>> This should have been: disables the degree of freedom (0-5)->(TX-Z,RX-Z)
>>>
>>> R.
>>>
>>>> So if you want to disable the rotations, just set the last three
>>>> diagonal values to 0.
>>>>
>>>> You can then use this solver in one of the inverse position solvers,
>>>> but the problem is that we do not have a solver yet that can take
>>>> these weights into account. But I do not think it should be to hard to
>>>> figure that out yourself when starting from the code of the iterative
>>>> solver for the inverse position kinematics:
>>>>
>>>> http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/cl
>>>> assK DL_1_1ChainIkSolverPos__NR.html
>>>>
>>>>
>>>> Ruben
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: IK with KDL

pibgeus
In reply to this post by Ruben Smits
Hi Ruben and Herman.
Thanks for your clarifications.

Finally we've implemented the code which solves the specified requirements. The source code is attached in this post. We hope it can help other people with the same problems. Basically the provided code contains two classes which are straightforward modifications of chainiksolverpos_nr and chainiksolverpos_nr_jl. They are called chainiksolverpos_nr_we and chainiksolverpos_nr_jl_we (weighed error).

These two classes provide a 6-dimensional weight vector which defines the influence each coordinate [XYZRPY] has in the error-checking stop predicate.
It allows to ignore, amplify or attenuate the influence of a specific coordinate.
For instance, if you need to reach some frame but you are not interested in some coordinates (like x position and yaw), it is possible to set the vector [0 1 1 1 1 0]. This approach can be used (and it may be recommendable in most of cases) together with the ik_solver_vel_wdls with the appropriate TS matrix specified.

Regards.

2010/12/6 Ruben Smits <[hidden email]>
On Sunday 05 December 2010 17:57:52 Pablo Iñigo Blasco wrote:
> Hi Ruben and ROS community!
>
> Our group is trying to use kdl IKs in a similar way as Herman says. We
> are also interested in relaxing some of the destination frame
> constraints. In our case we're only interested in the location of the
> end-effector, not its orientation. We've been having a look to all
> iksolvers (both position and velocity). As you said it seems easy to
> figure out how solve this problem from the existing code. However we
> are shuffling two alternatives:
>
> 1 - To implement a completely new iksolver_pos inspired in
> ChainIkSolverPos_NR_JL and ChainIkSolverVel_wdls (mainly changing the
> epsilon error check code taking into account the weights in the
> iksolver_pos too)
>
> 2 - To implement the "the mysterious unimplemented and uncommented"
> method: virtual int CartToJnt(const JntArray& q_init, const FrameVel&
> v_in, JntArrayVel& q_out) of the ChainIkSolverVel_wdls. It's curious,
> all of IkSolversVel have this method unimplemented. Why don't remove
> it? :-)
> We wonder if this method is supposed to solve the ikpos and ikvel
> simultaneously. What is the right semantic of this method?

That's exactly what it is supposed to do (according to the documentation of
the function: Calculate inverse position and velocity kinematics, from
cartesian position and velocity to joint positions and velocities)

I've introduced the function when I was playing with the idea that this was a
good thing. I'm not so sure anymore.

> Would such
> implementation be cohesive with the class responsibilities?

I think that might be the main problem. Because you loose the capability of
mixing different algorithms at the velocity and the position level.

> This is our theory since the output of this method is a JntArrayVel
> q_out object. We think that it could be implemented in this way:
> q_out = [q_end, delta_q] / q_end = ik(get_pose(v_in)) ^ delta_q =
> q_end - q_init.
> (alternatively, another interpretation for delta_q could be: delta_q=
> ik_vel(get_twist(v_in))
>
> Suggestions? Corrections?

After going through this I'm even more convinced the function should be
removed. There is no clean way to implement it generically.

Ruben

> Thank you.
>
>
> On Mon, Nov 15, 2010 at 11:34 AM, Ruben Smits
>
> <[hidden email]> wrote:
> > On Monday 15 November 2010 11:13:51 Ruben Smits wrote:
> > > On Thursday 11 November 2010 11:52:06 Jeroen Willems wrote:
> > > > On 2010-11-09 09:27, Herman Bruyninckx wrote:
> > > > > On Tue, 9 Nov 2010, Jeroen Willems wrote:
> > > > > > I have a question regarding the inverse kinematics using KDL.
> > > > > >
> > > > > > I would like to use carttojnt of the inverse kinematics solver.
> > > > > > The problem is I have to use a destination frame as input.
> > > > > > I'm using something similar to a elbow manipulator so you can
> > > > > > imagine I only want a reference position. The arm only can have
> > > > > > 2 poses to a reference position, to get the rotational part of
> > > > > > the frame I actually have to get the joint positions to
> > > > > > calculate it (correct me if I'm wrong).
> > > > > >
> > > > > > So
> > > > > > 1. Am I right?
> > > > > > 2. Could I use KDL to compute the IK or should I use an analytic
> > > > > > solution?
> > > > >
> > > > > The major issue with your problem is that "IK" does not make too
> > > > > much sense for a 2DOF system: when you don't take precautions the
> > > > > input frame will never lie in the span of your 2DOF, so you will
> > > > > have make a "projection" from the full 6D space onto your 2D
> > > > > subspace. KDL has algorithms to do that, but they make choices
> > > > > about how to project that might not correspond to your intuition.
> > > > > But that's inevitable.
> > > > >
> > > > > So, please try to formulate exactly what kind of input you would
> > > > > like or need to have.
> > > > >
> > > > > Herman
> > > > > _______________________________________________
> > > > > ros-users mailing list
> > > > > [hidden email]<mailto:[hidden email]>
> > > > > https://code.ros.org/mailman/listinfo/ros-users
> > > >
> > > > Thanks for the response.
> > > >
> > > > Okay to be more precise to give a better idea of what I'm doing.
> > > > I have an hexapod, so a torso with 6 legs consisting of 3 links
> > > > (without torso) and 3 joints. I want to be the tip/foot on an
> > > > specific point (x,y,z) in respect to the torso (thorax) so I have to
> > > > know the three joint positions to get there.
> > > >
> > > > So preferable without giving a rotation. So I'm really curious how to
> > > > obtain this or how to use a "projection".
> > >
> > > There is a inverse (CartToJnt) velocity solver in KDL that you can use
> > > to disable (or weigth)  some of the degrees of freedom in the
> > > cartesian space:
> > >
> > > http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/cl
> > > assK DL_1_1ChainIkSolverVel__wdls.html
> > >
> > > You can use the setWeightTS function for this. Setting a diagonal value
> > > of zero disables the joint, every other value neq 0 will be used as a
> > > weighting value.
> >
> > This should have been: disables the degree of freedom (0-5)->(TX-Z,RX-Z)
> >
> > R.
> >
> > > So if you want to disable the rotations, just set the last three
> > > diagonal values to 0.
> > >
> > > You can then use this solver in one of the inverse position solvers,
> > > but the problem is that we do not have a solver yet that can take
> > > these weights into account. But I do not think it should be to hard to
> > > figure that out yourself when starting from the code of the iterative
> > > solver for the inverse position kinematics:
> > >
> > > http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/cl
> > > assK DL_1_1ChainIkSolverPos__NR.html
> > >
> > >
> > > Ruben
> > > _______________________________________________
> > > ros-users mailing list
> > > [hidden email]
> > > https://code.ros.org/mailman/listinfo/ros-users
> >
> > _______________________________________________
> > ros-users mailing list
> > [hidden email]
> > https://code.ros.org/mailman/listinfo/ros-users
>
> --
> Pablo Iñigo Blasco.
> Computer Architecture Department. Universidad de Sevilla (Spain)
> http://es.linkedin.com/in/pibgeus | http://geus.wordpress.com



--
Pablo Iñigo Blasco.
Computer Architecture Department. Universidad de Sevilla (Spain)
http://es.linkedin.com/in/pibgeus | http://geus.wordpress.com


_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users

iksolvers_weighted_error.tar.gz (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IK with KDL

tuuzdu
This post has NOT been accepted by the mailing list yet.
In reply to this post by pibgeus
Hi, everyone!
I have a similar problem and I solved it like described in this topic.
Program works fine, but when I try calculate joints values more different than inital values, IK solver not found.

For example.
Inital frame of end-effector : 0.14208; -0.14555; -0.11145
Inital joints : 0, 0, 0

Desired frame : 0.16574, -0.1868, -0.08033

(delta_twist from hp_chainiksolverpos_nr_jl)

[ INFO] [1386694221.094697005]: delta_twist.vel 1: 0.023664 delta_twist.vel 2: -0.041252 delta_twist.vel 3: 0.031120 
[ INFO] [1386694221.094781119]: delta_twist.vel 1: 0.003682 delta_twist.vel 2: -0.006420 delta_twist.vel 3: -0.009216 
[ INFO] [1386694221.094833633]:
Joint 1: -0.000007
Joint 2: 0.245227
Joint 3: 0.211637
-----------------------------------------------

Desired frame : 0.098897, -0.25073, 0.053264 ( joints: 0.46, 0.73, 0.84)

[ INFO] [1386694869.786644209]:
delta_twist.vel 1: -0.043179 delta_twist.vel 2: -0.105182 delta_twist.vel 3: 0.164714 
[ INFO] [1386694869.786831916]:
delta_twist.vel 1: 0.024520 delta_twist.vel 2: -0.157306 delta_twist.vel 3: 0.083648 
[ INFO] [1386694869.786888482]:
delta_twist.vel 1: -0.016815 delta_twist.vel 2: -0.191048 delta_twist.vel 3: 0.084714 
[ INFO] [1386694869.786932308]:
delta_twist.vel 1: 0.036921 delta_twist.vel 2: -0.185430 delta_twist.vel 3: 0.084714 
[ INFO] [1386694869.786992199]:
delta_twist.vel 1: -0.014347 delta_twist.vel 2: -0.214840 delta_twist.vel 3: 0.084714 
[ INFO] [1386694869.787067596]:
delta_twist.vel 1: 0.036921 delta_twist.vel 2: -0.185430 delta_twist.vel 3: 0.084714 
[ INFO] [1386694869.787110975]:
delta_twist.vel 1: -0.014347 delta_twist.vel 2: -0.214840 delta_twist.vel 3: 0.084714 
[ INFO] [1386694869.787151938]:
delta_twist.vel 1: 0.036921 delta_twist.vel 2: -0.185430 delta_twist.vel 3: 0.084714 
[ INFO] [1386694869.787192158]:
delta_twist.vel 1: -0.014347 delta_twist.vel 2: -0.214840 delta_twist.vel 3: 0.084714 
[ INFO] [1386694869.787235519]:
delta_twist.vel 1: 0.036921 delta_twist.vel 2: -0.185430 delta_twist.vel 3: 0.084714
[ERROR] [1386694869.787273642]: IK not found

I can not understand what the problem is...
leg_kinematics.cpp
hp_chainiksolverpos_nr_jl.cpp