[ros-users] IK with KDL

Thu Dec 9 01:31:08 UTC 2010

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 <ruben.smits at mech.kuleuven.be>

> 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
> >
> > <ruben.smits at mech.kuleuven.be> 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
> > > > > > ros-users at code.ros.org<mailto:ros-users at code.ros.org>
> > > > > > 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<http://people.mech.kuleuven.be/%7Eorocos/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<http://people.mech.kuleuven.be/%7Eorocos/pub/devel/kdl/latest/api/html/cl>
> > > > assK DL_1_1ChainIkSolverPos__NR.html
> > > >
> > > >
> > > > Ruben
> > > > _______________________________________________
> > > > ros-users mailing list
> > > > ros-users at code.ros.org
> > > > https://code.ros.org/mailman/listinfo/ros-users
> > >
> > > _______________________________________________
> > > ros-users mailing list
> > > ros-users at code.ros.org
> > > https://code.ros.org/mailman/listinfo/ros-users
> >
> > --
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20101209/7718fbcb/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iksolvers_weighted_error.tar.gz
Type: application/x-gzip
Size: 2427 bytes
Desc: not available
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20101209/7718fbcb/attachment-0005.bin>