KDL | ABB 6400 kinematic model || external axis

hi,

I've adapted the example KUKA definition to an ABB IRB6400. The next step is to model external axis; for instance a linear track and an orbit table [ aka welding table ]. I can still picture modeling the linear track as a segment that precedes the first joint, though I have a harder time coming up with a way to model the external axis. Perhaps what I'm struggling with is largely semantically; I need to adapt my [limited] understanding of things to KDL's semantics. Finally, its perhaps worth mentioning that I'm using PyKDL, the python bindings of KDL.

1) should all my axis be part of a Chain object? 2) the linear track is still directly mounted to the robot. should I model the distance between the robot and the orbit table by a Segment that has a Joint::None, and continue the chain when the position of the orbit table is reached?

linear track -> abb 6400 -> "spacer" joint -> orbit table

some coincident questions:

3) well, more of a request really; the "ChainIkSolverPos_NR_JL" class is missing in the python wrappers. perhaps an idea to throw it on the TODO stack? i'll have a stab at it as well... 4) obviously a number of kinematic configurations are possible to reach a certain position. hence my surprise that there is no API that addresses this issue. I'm assuming this is by design, so I'm curious to know the motivation why. Excuse my curiosity, I haven't been able to find something on the mathematical principles / details wrt KDL's algorithm, so if you have a pointer perhaps? 5) does the "ChainIkSolverVel_wdls" class allow me to weight a preference for certain joints? for instance, can I use it to prefer movement of the orbit table rather than the 1st joint of the ABB 6400? I realize this is a velocity solver, so my question is whether this is a shortcut to impose preference / weightings on the joints to move?

Many thanks in advance, and thank you for making orocos / KDL open source.

-jelle

KDL | ABB 6400 kinematic model || external axis

On Mon, 26 Sep 2011, jelleferinga [..] ... wrote:

> I've adapted the example KUKA definition to an ABB IRB6400. The next step
> is to model external axis; for instance a linear track and an orbit table
> [ aka welding table ]. I can still picture modeling the linear track as a
> segment that precedes the first joint, though I have a harder time coming
> up with a way to model the external axis.

I would model the linear track and the orbit table as two independent
kinematic chains, and not as part of the robot's kinematic chain.

When composing two or all three of them together, you will have to
introduce a "Coordinator" for the composition (responsible for deciding how
to "split" a task's motion requirements over the different available
sub-systems: robot, track, table), and that's perfectly fine. The simplest
(but not necessarily the best) way this Coordinator can work is to add the
individual Chains into one single, composite Chain, and add "appropriate"
weigths to the composite set of joints.

> Perhaps what I'm struggling
> with is largely semantically; I need to adapt my [limited] understanding
> of things to KDL's semantics. Finally, its perhaps worth mentioning that
> I'm using PyKDL, the python bindings of KDL.

The language bindings are of secondary importance, I guess.

> 1) should all my axis be part of a Chain object?

The will be part of three different Chain objects.

> 2) the linear track is still directly mounted to the robot. should I
> model the distance between the robot and the orbit table by a Segment
> that has a Joint::None, and continue the chain when the position of the
> orbit table is reached?

Don't put them in the same Chain :-)

> linear track -> abb 6400 -> "spacer" joint -> orbit table
>
> some coincident questions:
>
> 3) well, more of a request really; the "ChainIkSolverPos_NR_JL" class is
> missing in the python wrappers. perhaps an idea to throw it on the TODO
> stack? i'll have a stab at it as well...

> 4) obviously a number of kinematic configurations are possible to reach a
> certain position. hence my surprise that there is no API that addresses
> this issue.

Several solvers _do_ deal with redundancy resolution. There are no KDL
algorithms that give you all possible configurations for a given desired
end-effector pose.

> I'm assuming this is by design, so I'm curious to know the
> motivation why. Excuse my curiosity, I haven't been able to find
> something on the mathematical principles / details wrt KDL's algorithm,
> so if you have a pointer perhaps?

KDL is focusing on the algorithms that one needs to do _control_ and
_perception_, not _planning_. Hence. current algorithms are
_instantaneous_, in other words, the configuration is the one the robot is
currently in. Which is _always_ the case when you work with a _real_ robot,
by the way :-)

> 5) does the "ChainIkSolverVel_wdls" class allow me to weight a preference
> for certain joints? for instance, can I use it to prefer movement of the
> orbit table rather than the 1st joint of the ABB 6400?

Yes.

> I realize this is a velocity solver, so my question is whether this is a
> shortcut to impose preference / weightings on the joints to move?
I don't fully understand your question... The fact that weighting is
possible is independent of the fact whether one solves at the velocity
level or at other levels (e.g., torque or acceleration).

> Many thanks in advance, and thank you for making orocos / KDL open source.
>
> -jelle

Herman

KDL | ABB 6400 kinematic model || external axis

Dear Herman,

Many thanks for your most informative reply.

> I would model the linear track and the orbit table as two independent
> kinematic chains, and not as part of the robot's kinematic chain.
>

Thanks, I couldnt figure that out for myself...

> When composing two or all three of them together, you will have to
> introduce a "Coordinator" for the composition (responsible for deciding how
> to "split" a task's motion requirements over the different available
> sub-systems: robot, track, table), and that's perfectly fine. The simplest
> (but not necessarily the best) way this Coordinator can work is to add the
> individual Chains into one single, composite Chain, and add "appropriate"
> weigths to the composite set of joints.
>

That'll be an interesting challenge... but many thanks for suggesting this
pattern, I'll take that to heart...

> 2) the linear track is still directly mounted to the robot. should I
>
> model the distance between the robot and the orbit table by a Segment
>> that has a Joint::None, and continue the chain when the position of the
>> orbit table is reached?
>>
>
> Don't put them in the same Chain :-)
>

That resolves the semantic part of my question, cool...

> KDL is focusing on the algorithms that one needs to do _control_ and
> _perception_, not _planning_. Hence. current algorithms are
> _instantaneous_, in other words, the configuration is the one the robot is
> currently in. Which is _always_ the case when you work with a _real_ robot,
> by the way :-)
>

I love getting answers to question I was too naive to formulate... thanks...

> 5) does the "ChainIkSolverVel_wdls" class allow me to weight a preference
>> for certain joints? for instance, can I use it to prefer movement of the
>> orbit table rather than the 1st joint of the ABB 6400?
>>
>
> Yes.
>

That's it! Thanks so much, ready for my big leap fwd now...
Again, much appreciated, I hope to contribute to extending the python
wrappers.

-jelle