Inverse position kinematics that takes into account joinlimits

On Thu, 27 Nov 2008, Ruben Smits wrote:

> Hi KDL code reviewers,
>
> In the attachment you can find the code for a inverse position
> kinematics algorithm that can take into account the joint limits.
>
> This is a very small adaption to the existing chainiksolverpos_nr, it
> will reset the joints back to the limits if they are violated.
>
> If no one subjects i will commit it to trunk soon.
>
You follow a very simplistic approach in this algorithm: if the nominally
calculated joint position is out of its bounds, you put it to the bounds in
a hard and unconditional way. This is Not Good... For one thing, it will
introduce very strong dynamics into your robot control system: the hard
boundaries are infinitely stiff stops; I also expect oscillatory behaviour,
when the boundary is violated at one sample time, and not violated in the
next, so that you keep asking for joint velocities that "bang" against the
constraints. For another thing, the policy about _how_ to cope with
reaching boundaries should not be hardcoded in the IK, but in the overall
motion specification and control component...
So, what we have to come up with is a design that allows this decoupling
between IK solver and constraint violation, because the IK solvers _have_
to be able to take this constraint violations into account, since they are
the major source to detect the problem. For solvers that take forces and
dynamics into account, it will be easy: every boundary violation policy
will result in some form of instantaneous repelling joint force. For the
purely kinematic case, I don't know (yet).

Herman

Inverse position kinematics that takes into account joinlimits

On Mon, 1 Dec 2008, Herman Bruyninckx wrote:

>>
>> In the attachment you can find the code for a inverse position
>> kinematics algorithm that can take into account the joint limits.
>>
>> This is a very small adaption to the existing chainiksolverpos_nr, it
>> will reset the joints back to the limits if they are violated.
>>
>> If no one subjects i will commit it to trunk soon.
>>
> You follow a very simplistic approach in this algorithm: if the nominally
> calculated joint position is out of its bounds, you put it to the bounds in
> a hard and unconditional way. This is Not Good... For one thing, it will
> introduce very strong dynamics into your robot control system: the hard
> boundaries are infinitely stiff stops; I also expect oscillatory behaviour,
> when the boundary is violated at one sample time, and not violated in the
> next, so that you keep asking for joint velocities that "bang" against the
> constraints. For another thing, the policy about _how_ to cope with
> reaching boundaries should not be hardcoded in the IK, but in the overall
> motion specification and control component...
> So, what we have to come up with is a design that allows this decoupling
> between IK solver and constraint violation, because the IK solvers _have_
> to be able to take this constraint violations into account, since they are
> the major source to detect the problem. For solvers that take forces and
> dynamics into account, it will be easy: every boundary violation policy
> will result in some form of instantaneous repelling joint force. For the
> purely kinematic case, I don't know (yet).
>
I forgot the important part of my message... :-)

If you are interested in this joint limit violation feature, please post a
message making your use case clear (why do you need it exactly, under what
circumstances), so that we can make a suggestion about how to do it
"properly"... I acknowledge the need for this kind of functionality, but I
am very convinced that letting the IK solver make the decision about _how_
to do it is not the right thing...

Herman