http://bugs.orocos.org/show_bug.cgi?id=967

Summary: Using path-like specification to create joints

Product: KDL

Version: unspecified

Platform: All

OS/Version: All

Status: NEW

Severity: enhancement

Priority: P3

Component: Kinematic chains

AssignedTo: orocos-dev [..] ...

ReportedBy: gianni [dot] borghesan [..] ...

CC: orocos-dev [..] ...

Estimated Hours: 0.0

It would be useful to use paths for specifying joints:

In this way, it would be possible to create virtual kinematic chains where one

of the joint does not belong to the "classical" joint list but can be a path.

By adding such feature it could be possible to use inverse kinematics.

## [Bug 967] Using path-like specification to create joints

http://bugs.orocos.org/show_bug.cgi?id=967

Herman Bruyninckx <herman [dot] bruyninckx [..] ...> changed:

What |Removed |Added

----------------------------------------------------------------------------

CC| |herman [dot] bruyninckx [..] ...

| |uven.be

## [Bug 967] Using path-like specification to create joints

On 06/12/2012 10:16 PM, Herman Bruyninckx wrote:

> http://bugs.orocos.org/show_bug.cgi?id=967

>

> Herman Bruyninckx<herman [dot] bruyninckx [..] ...> changed:

>

> What |Removed |Added

> ----------------------------------------------------------------------------

> CC| |herman [dot] bruyninckx [..] ...

> | |uven.be

>

## [Bug 967] Using path-like specification to create joints

On Wed, 13 Jun 2012, Erwin Aertbelien wrote:

> On 06/12/2012 10:16 PM, Herman Bruyninckx wrote:

>> http://bugs.orocos.org/show_bug.cgi?id=967

>>

>> Herman Bruyninckx<herman [dot] bruyninckx [..] ...> changed:

>>

>> What |Removed |Added

>> ----------------------------------------------------------------------------

>> CC|

>> |herman [dot] bruyninckx [..] ...

>> | | uven.be

>>

>> --- Comment #1 from Herman Bruyninckx<herman [dot] bruyninckx [..] ...>

>> 2012-06-12 22:16:01 CEST ---

>> (In reply to comment #0)

>> > It would be useful to use paths for specifying joints:

>> > In this way, it would be possible to create virtual kinematic chains

>> > where one

>> > of the joint does not belong to the "classical" joint list but can be a

>> > path.

>> > By adding such feature it could be possible to use inverse kinematics.

>> I do not fully understand your motivation... Can you give concrete

>> examples of

>> such joints that need a "path"? Maybe you are thinking of "human like"

>> joints,

>> such as elbows or shoulders, that are rather complex, non-ideal kinematic

>> chains in themselves...?

>

>

> - An example of a use case would be in the implementation of a virtual path

> along which we want to constraint (parts) of the motion of a robot.

>

> - Another use case would indeed be non-ideal joints such as the human knee.

>

> - Another argument for their use is that they happen to have a very similar

> interface, so why not reuse everything that is possible.

>

> - It would also allow to bring in the geometric part of a trajectory inside a

> scenegraph. This would then allow a bigger part

> of an iTasc specification to be modelled instead of programmed. (+ it opens

> up newly possible iTasc specifications where

> the joint along the trajectory is left free and adaptable to the task).

>

>

>>

>> I do agree with the addition of N-DOF joints, such as spherical ones, or

>> mobile

>> bases, etc.

>>

> But what is the difference between an N-dof joint and a robot ?

> And what to do with the dynamics.

I answer two remarks at the same time, because they _are_ intrinsically

linked: an N-dof joint _must_ have an N-dof dynamics algorithm, and not the

N-times-1 unphysical models that people are typically using. More

concretely, in the inverse dynamics the 1-DOF scalar inversions must be

replaced by the inverse of a linear N-DOF system. For example, a mobile

platform is _not_ a serial P-P-R joint, but really a Nx3 (N>=3) joint, with

N motors driving 3 mechanical DOFs.

PS N-DOF joints require a remodelling of the JointSpace data structures.

Herman

## [Bug 967] Using path-like specification to create joints

On 06/13/2012 02:30 PM, Herman Bruyninckx wrote:

> On Wed, 13 Jun 2012, Erwin Aertbelien wrote:

>

>> On 06/12/2012 10:16 PM, Herman Bruyninckx wrote:

>>> http://bugs.orocos.org/show_bug.cgi?id=967

>>>

>>> Herman Bruyninckx<herman [dot] bruyninckx [..] ...> changed:

>>>

>>> What |Removed |Added

>>> ----------------------------------------------------------------------------

>>>

>>> CC|

>>> |herman [dot] bruyninckx [..] ...

>>> | | uven.be

>>>

>>> --- Comment #1 from Herman

>>> Bruyninckx<herman [dot] bruyninckx [..] ...>

>>> 2012-06-12 22:16:01 CEST ---

>>> (In reply to comment #0)

>>> > It would be useful to use paths for specifying joints:

>>> > In this way, it would be possible to create virtual kinematic

>>> chains > where one

>>> > of the joint does not belong to the "classical" joint list but

>>> can be a > path.

>>> > By adding such feature it could be possible to use inverse

>>> kinematics.

>>> I do not fully understand your motivation... Can you give concrete

>>> examples of

>>> such joints that need a "path"? Maybe you are thinking of "human

>>> like"

>>> joints,

>>> such as elbows or shoulders, that are rather complex, non-ideal

>>> kinematic

>>> chains in themselves...?

>>

>>

>> - An example of a use case would be in the implementation of a

>> virtual path along which we want to constraint (parts) of the motion

>> of a robot.

>>

>> - Another use case would indeed be non-ideal joints such as the human

>> knee.

>>

>> - Another argument for their use is that they happen to have a very

>> similar interface, so why not reuse everything that is possible.

>>

>> - It would also allow to bring in the geometric part of a trajectory

>> inside a scenegraph. This would then allow a bigger part

>> of an iTasc specification to be modelled instead of programmed. (+ it

>> opens up newly possible iTasc specifications where

>> the joint along the trajectory is left free and adaptable to the task).

>>

>>

>>>

>>> I do agree with the addition of N-DOF joints, such as spherical

>>> ones, or

>>> mobile

>>> bases, etc.

>>>

>> But what is the difference between an N-dof joint and a robot ?

>> And what to do with the dynamics.

>

> I answer two remarks at the same time, because they _are_ intrinsically

> linked: an N-dof joint _must_ have an N-dof dynamics algorithm, and

> not the

> N-times-1 unphysical models that people are typically using. More

> concretely, in the inverse dynamics the 1-DOF scalar inversions must be

> replaced by the inverse of a linear N-DOF system. For example, a mobile

> platform is _not_ a serial P-P-R joint, but really a Nx3 (N>=3) joint,

> with

> N motors driving 3 mechanical DOFs.

Good example.

The non-holonomicity of the example leaves me confused on the what

interface (methods/properties) the Joint data structure should have.

Currently it has:

Frame Pos( double q) const

Twist Twist( double qdot) const

and some introspection methods

Which is clearly not sufficient for a general joint,

(1) A 1-dof joint could have, in pseudo-code:

Frame Pos(double q) const

Twist Twist(double q, double qdot) const

Twist AccelerationTwist(double q,double qdot, double qdotdot) const

(2) If we extend this to N-dof holonomic, this becomes in pseudo-code:

Frame Pos(doubleArray q) const

Twist Twist(doubleArray q, doubleArray qdot) const

Twist AccelerationTwist(doubleArray q, doubleArray qdot,

doubleArray qdotdot) const

Matrix Jacobian(doubleArray q) const

Matrix JacobianDerivative(doubleArray q,doubleArray qdot) const

As you can see, I added some Jacobian/JacobianDerivative functions in

this case. For the 1-dof

case these methods were trivially equivalent to the Twist and

AccelerationTwist.

I do not yet consider which twist/acc. twist we are going to use.

(3) But for the N-dof non-holonomic case of the above example, I do not

know what would be our

definition of the Joint class ??

If we do not have such a N-dof non-holonomic joint, how can we represent

the above example in KDL or above KDL

(e.g. with a massless P-P-R serial joint, together with differential

constraints) ?

Note on the side:

in Ruben's implementation we have inertia,damping, stiffness specified

in the constructors for the joints,

but there is no way that these properties are ever used, because it is

not exposed (explicitly or implicitly) outside the

Joint class. Does somebody knows the reasoning behind this ?

Does a Joint by itself contains dynamics ? Or should the dynamics only

be represented by the Segment class ?

>

> PS N-DOF joints require a remodelling of the JointSpace data structures.

>

> Herman

>

## [Bug 967] Using path-like specification to create joints

On Wed, 13 Jun 2012, Erwin Aertbelien wrote:

[...]

>> > > I do agree with the addition of N-DOF joints, such as spherical ones,

>> > > or

>> > > mobile

>> > > bases, etc.

>> > >

>> > But what is the difference between an N-dof joint and a robot ?

>> > And what to do with the dynamics.

>>

>> I answer two remarks at the same time, because they _are_ intrinsically

>> linked: an N-dof joint _must_ have an N-dof dynamics algorithm, and not

>> the

>> N-times-1 unphysical models that people are typically using. More

>> concretely, in the inverse dynamics the 1-DOF scalar inversions must be

>> replaced by the inverse of a linear N-DOF system. For example, a mobile

>> platform is _not_ a serial P-P-R joint, but really a Nx3 (N>=3) joint,

>> with

>> N motors driving 3 mechanical DOFs.

> Good example.

>

> The non-holonomicity of the example leaves me confused on the what

> interface (methods/properties) the Joint data structure should have.

It does not make much sense, really, _because_ of the non-holonomicity. In

other words, the joint values are _not_ a faithful representation of the

state of the mobile platform.

> Currently it has:

> Frame Pos( double q) const

> Twist Twist( double qdot) const

>

> and some introspection methods

>

> Which is clearly not sufficient for a general joint,

> (1) A 1-dof joint could have, in pseudo-code:

> Frame Pos(double q) const

> Twist Twist(double q, double qdot) const

> Twist AccelerationTwist(double q,double qdot, double qdotdot) const

Yes.

> (2) If we extend this to N-dof holonomic, this becomes in pseudo-code:

> Frame Pos(doubleArray q) const

> Twist Twist(doubleArray q, doubleArray qdot) const

> Twist AccelerationTwist(doubleArray q, doubleArray qdot,

> doubleArray qdotdot) const

> Matrix Jacobian(doubleArray q) const

> Matrix JacobianDerivative(doubleArray q,doubleArray qdot) const

"N-dof holonomic" _is_ a kinematic chain, so I would not introduce a

separate primitive for it.

> As you can see, I added some Jacobian/JacobianDerivative functions in this

> case. For the 1-dof case these methods were trivially equivalent to the

> Twist and AccelerationTwist.

Indeed.

> I do not yet consider which twist/acc. twist we are going to use.

>

> (3) But for the N-dof non-holonomic case of the above example, I do not know

> what would be our definition of the Joint class ??

It does not make real sense, since the joint value is _not_ a state

parameter. Pos and Jacobian of a non-holonomic system are dependent on the

_Cartesian_ state (which is really a state) and the change in joint angles.

> If we do not have such a N-dof non-holonomic joint, how can we represent the

> above example in KDL or above KDL

> (e.g. with a massless P-P-R serial joint, together with differential

> constraints) ?

KDL can currently not represent such systems faithfully.

> Note on the side:

> in Ruben's implementation we have inertia,damping, stiffness specified in the

> constructors for the joints,

> but there is no way that these properties are ever used, because it is not

> exposed (explicitly or implicitly) outside the

> Joint class. Does somebody knows the reasoning behind this ?

The reasoning was okay (dynamics _is_ useful), but the implementation was

wrong: too much information hiding :-)

> Does a Joint by itself contains dynamics ? Or should the dynamics only be

> represented by the Segment class ?

I am advocating since quite some time (and it was in the original _design_

of KDL that I made with Ruben) to introduce the extra classes of "Actuator"

(which has actuation dynamics, possibly mechanical, but also electrical,

pneumatic,...) and "Transmission" (which has the mechanical dynamics you

mention) and let the "Joint" represent the purely kinematic, ideal concept.

Herman

## [KDL] Joints and dynamics in KDL (was: [Bug 967] Using path-like

On 06/13/2012 03:50 PM, Herman Bruyninckx wrote:

> [...]

>

>> Note on the side:

>> in Ruben's implementation we have inertia,damping, stiffness

>> specified in the constructors for the joints,

>> but there is no way that these properties are ever used, because it

>> is not exposed (explicitly or implicitly) outside the

>> Joint class. Does somebody knows the reasoning behind this ?

>

> The reasoning was okay (dynamics _is_ useful), but the implementation was

> wrong: too much information hiding :-)

>

>> Does a Joint by itself contains dynamics ? Or should the dynamics

>> only be represented by the Segment class ?

>

> I am advocating since quite some time (and it was in the original

> _design_

> of KDL that I made with Ruben) to introduce the extra classes of

> "Actuator"

> (which has actuation dynamics, possibly mechanical, but also electrical,

> pneumatic,...) and "Transmission" (which has the mechanical dynamics you

> mention) and let the "Joint" represent the purely kinematic, ideal

> concept.

>

> Herman

Intuitively, I would turn this upside-down: Joint is a class that also

has knowledge

about dynamics, i.e. you can ask its mass matrix, damping matrix, you

can ask forces given joint inputs, ....

This Joint can however also aggregate an underlying Actuator class (

which can correspond to a 1-dof physical system).

Transmission would just be a another class of type Actuator ( that,

underlying, aggregates another Actuator).

There is however, a remaining problem with this approach ( and with

Herman's proposal):

when you start to introduce underlying dynamics, your state can be

larger then only the (q,qdot) you give along to the methods,

The question then becomes, can our algorithms for dynamics handle

this ? (at least, in principle).

## [KDL] Joints and dynamics in KDL (was: [Bug 967] Using path-like

On Wed, 13 Jun 2012, Erwin Aertbelien wrote:

> On 06/13/2012 03:50 PM, Herman Bruyninckx wrote:

>> [...]

>>

>> > Note on the side:

>> > in Ruben's implementation we have inertia,damping, stiffness specified

>> > in the constructors for the joints,

>> > but there is no way that these properties are ever used, because it is

>> > not exposed (explicitly or implicitly) outside the

>> > Joint class. Does somebody knows the reasoning behind this ?

>>

>> The reasoning was okay (dynamics _is_ useful), but the implementation was

>> wrong: too much information hiding :-)

>>

>> > Does a Joint by itself contains dynamics ? Or should the dynamics only

>> > be represented by the Segment class ?

>>

>> I am advocating since quite some time (and it was in the original _design_

>> of KDL that I made with Ruben) to introduce the extra classes of

>> "Actuator"

>> (which has actuation dynamics, possibly mechanical, but also electrical,

>> pneumatic,...) and "Transmission" (which has the mechanical dynamics you

>> mention) and let the "Joint" represent the purely kinematic, ideal

>> concept.

>>

>> Herman

> Intuitively, I would turn this upside-down: Joint is a class that also has

> knowledge

> about dynamics, i.e. you can ask its mass matrix, damping matrix, you can ask

> forces given joint inputs, ....

This is a "Joint" primitive in the context of a real robot, while I was

refering to the "Joint" as an ideal kinematic primitive. Both are valid,

and necessary, but they are semantically two different things. So, it makes

sense to introduce semantically clearly different names.

"GeometricJoint" and "MechanicalJoint" are creativity-less suggestions...

> This Joint can however also aggregate an underlying Actuator class ( which

> can correspond to a 1-dof physical system).

The "MechanicalJoint" is indeed the _composition_ of all the other

primitives: GeometricJoint, Transmission, Actuator, and the links with the

Segments the MechanicalJoint is connecting.

> Transmission would just be a another class of type Actuator ( that,

> underlying, aggregates another Actuator).

I disagree. For the semantic reason that:

- Actuators are "transformers" of several physical domains (electrical,

hydraulic, chemical, thermal,...) to the mechanical domain;

- Transmission is a transformer from the mechanical domain to the

mechanical domain.

> There is however, a remaining problem with this approach ( and with Herman's

> proposal):

> when you start to introduce underlying dynamics, your state can be larger

> then only the (q,qdot) you give along to the methods,

Yes, but it would be decomposed nicely according to the sub-classes of the

different physical domains. The composition into a "MechanicalJoint" is

then rather straightforward.

> The question then becomes, can our algorithms for dynamics handle this ?

> (at least, in principle).

In principle, yes, in current practice, no. I would do it outside of KDL,

in a "Physical Modelling Library" project (like Modelica is now doing), and

keep KDL limited to kinematics and (_mechanical_) dynamics.

Herman

## [Bug 967] Using path-like specification to create joints

On 06/13/2012 03:50 PM, Herman Bruyninckx wrote:

> On Wed, 13 Jun 2012, Erwin Aertbelien wrote:

>

> [...]

>>> > > I do agree with the addition of N-DOF joints, such as spherical

>>> ones, > > or

>>> > > mobile

>>> > > bases, etc.

>>> > > > But what is the difference between an N-dof joint and a robot ?

>>> > And what to do with the dynamics.

>>>

>>> I answer two remarks at the same time, because they _are_

>>> intrinsically

>>> linked: an N-dof joint _must_ have an N-dof dynamics algorithm, and

>>> not

>>> the

>>> N-times-1 unphysical models that people are typically using. More

>>> concretely, in the inverse dynamics the 1-DOF scalar inversions

>>> must be

>>> replaced by the inverse of a linear N-DOF system. For example, a

>>> mobile

>>> platform is _not_ a serial P-P-R joint, but really a Nx3 (N>=3) joint,

>>> with

>>> N motors driving 3 mechanical DOFs.

>> Good example.

>>

>> The non-holonomicity of the example leaves me confused on the what

>> interface (methods/properties) the Joint data structure should have.

>

> It does not make much sense, really, _because_ of the

> non-holonomicity. In

> other words, the joint values are _not_ a faithful representation of the

> state of the mobile platform.

>

>> Currently it has:

>> Frame Pos( double q) const

>> Twist Twist( double qdot) const

>>

>> and some introspection methods

>>

>> Which is clearly not sufficient for a general joint,

>> (1) A 1-dof joint could have, in pseudo-code:

>> Frame Pos(double q) const

>> Twist Twist(double q, double qdot) const

>> Twist AccelerationTwist(double q,double qdot, double qdotdot)

>> const

>

> Yes.

>

>> (2) If we extend this to N-dof holonomic, this becomes in pseudo-code:

>> Frame Pos(doubleArray q) const

>> Twist Twist(doubleArray q, doubleArray qdot) const

>> Twist AccelerationTwist(doubleArray q, doubleArray qdot,

>> doubleArray qdotdot) const

>> Matrix Jacobian(doubleArray q) const

>> Matrix JacobianDerivative(doubleArray q,doubleArray qdot) const

>

> "N-dof holonomic" _is_ a kinematic chain, so I would not introduce a

> separate primitive for it.

So the same conclusion is reached as in my original remark: the N-dof

holonomic case is captured by the "Chain" concept,

and no N-dof should be introduced.

Gianni, did you had other use cases for N-dof joints ?

>

>> As you can see, I added some Jacobian/JacobianDerivative functions in

>> this case. For the 1-dof case these methods were trivially

>> equivalent to the

>> Twist and AccelerationTwist.

>

> Indeed.

>

>> I do not yet consider which twist/acc. twist we are going to use.

>>

>> (3) But for the N-dof non-holonomic case of the above example, I do

>> not know what would be our definition of the Joint class ??

>

> It does not make real sense, since the joint value is _not_ a state

> parameter. Pos and Jacobian of a non-holonomic system are dependent on

> the

> _Cartesian_ state (which is really a state) and the change in joint

> angles.

Conclusion: We do not consider these non-holonomic cases in the

modelling of the Chain/Joints. It is modelled

outside these concepts.

>

>> If we do not have such a N-dof non-holonomic joint, how can we

>> represent the above example in KDL or above KDL

>> (e.g. with a massless P-P-R serial joint, together with differential

>> constraints) ?

>

> KDL can currently not represent such systems faithfully.

>

>> Note on the side:

>> in Ruben's implementation we have inertia,damping, stiffness

>> specified in the constructors for the joints,

>> but there is no way that these properties are ever used, because it

>> is not exposed (explicitly or implicitly) outside the

>> Joint class. Does somebody knows the reasoning behind this ?

>

> The reasoning was okay (dynamics _is_ useful), but the implementation was

> wrong: too much information hiding :-)

>

>> Does a Joint by itself contains dynamics ? Or should the dynamics

>> only be represented by the Segment class ?

>

> I am advocating since quite some time (and it was in the original

> _design_

> of KDL that I made with Ruben) to introduce the extra classes of

> "Actuator"

> (which has actuation dynamics, possibly mechanical, but also electrical,

> pneumatic,...) and "Transmission" (which has the mechanical dynamics you

> mention) and let the "Joint" represent the purely kinematic, ideal

> concept.

>

> Herman

## [Bug 967] Using path-like specification to create joints

On Wed, 13 Jun 2012, Erwin Aertbelien wrote:

> On 06/13/2012 03:50 PM, Herman Bruyninckx wrote:

>> On Wed, 13 Jun 2012, Erwin Aertbelien wrote:

>>

>> [...]

>> > > > > I do agree with the addition of N-DOF joints, such as spherical

>> > > ones, > > or

>> > > > > mobile

>> > > > > bases, etc.

>> > > > > > But what is the difference between an N-dof joint and a robot ?

>> > > > And what to do with the dynamics.

>> > >

>> > > I answer two remarks at the same time, because they _are_

>> > > intrinsically

>> > > linked: an N-dof joint _must_ have an N-dof dynamics algorithm, and

>> > > not

>> > > the

>> > > N-times-1 unphysical models that people are typically using. More

>> > > concretely, in the inverse dynamics the 1-DOF scalar inversions

>> > > must be

>> > > replaced by the inverse of a linear N-DOF system. For example, a

>> > > mobile

>> > > platform is _not_ a serial P-P-R joint, but really a Nx3 (N>=3)

>> > > joint,

>> > > with

>> > > N motors driving 3 mechanical DOFs.

>> > Good example.

>> >

>> > The non-holonomicity of the example leaves me confused on the what

>> > interface (methods/properties) the Joint data structure should have.

>>

>> It does not make much sense, really, _because_ of the non-holonomicity. In

>> other words, the joint values are _not_ a faithful representation of the

>> state of the mobile platform.

>>

>> > Currently it has:

>> > Frame Pos( double q) const

>> > Twist Twist( double qdot) const

>> >

>> > and some introspection methods

>> >

>> > Which is clearly not sufficient for a general joint,

>> > (1) A 1-dof joint could have, in pseudo-code:

>> > Frame Pos(double q) const

>> > Twist Twist(double q, double qdot) const

>> > Twist AccelerationTwist(double q,double qdot, double qdotdot)

>> > const

>>

>> Yes.

>>

>> > (2) If we extend this to N-dof holonomic, this becomes in pseudo-code:

>> > Frame Pos(doubleArray q) const

>> > Twist Twist(doubleArray q, doubleArray qdot) const

>> > Twist AccelerationTwist(doubleArray q, doubleArray qdot,

>> > doubleArray qdotdot) const

>> > Matrix Jacobian(doubleArray q) const

>> > Matrix JacobianDerivative(doubleArray q,doubleArray qdot) const

>>

>> "N-dof holonomic" _is_ a kinematic chain, so I would not introduce a

>> separate primitive for it.

> So the same conclusion is reached as in my original remark: the N-dof

> holonomic case is captured by the "Chain" concept,

> and no N-dof should be introduced.

Agreed.

> Gianni, did you had other use cases for N-dof joints ?

>> > As you can see, I added some Jacobian/JacobianDerivative functions in

>> > this case. For the 1-dof case these methods were trivially equivalent

>> > to the

>> > Twist and AccelerationTwist.

>>

>> Indeed.

>>

>> > I do not yet consider which twist/acc. twist we are going to use.

>> >

>> > (3) But for the N-dof non-holonomic case of the above example, I do not

>> > know what would be our definition of the Joint class ??

>>

>> It does not make real sense, since the joint value is _not_ a state

>> parameter. Pos and Jacobian of a non-holonomic system are dependent on the

>> _Cartesian_ state (which is really a state) and the change in joint

>> angles.

> Conclusion: We do not consider these non-holonomic cases in the modelling of

> the Chain/Joints. It is modelled outside these concepts.

I agree.

But this puts the question to somewhere else: do we decide to add these

"other concepts" to KDL or not?

Personally, I am in favour of doing so. But not without a decent

preparation and discussion via the list.

Enea and Azamat have already explored the issue a bit further, in the

context of extending the Vereshchagin dynamics code to mobile platforms.

Herman

## [Bug 967] Using path-like specification to create joints

On 06/13/2012 04:07 PM, Erwin Aertbelien wrote:

> On 06/13/2012 03:50 PM, Herman Bruyninckx wrote:

>> On Wed, 13 Jun 2012, Erwin Aertbelien wrote:

>>

>> [...]

>>>> > > I do agree with the addition of N-DOF joints, such as spherical

>>>> ones, > > or

>>>> > > mobile

>>>> > > bases, etc.

>>>> > > > But what is the difference between an N-dof joint and a robot ?

>>>> > And what to do with the dynamics.

>>>>

>>>> I answer two remarks at the same time, because they _are_ intrinsically

>>>> linked: an N-dof joint _must_ have an N-dof dynamics algorithm, and not

>>>> the

>>>> N-times-1 unphysical models that people are typically using. More

>>>> concretely, in the inverse dynamics the 1-DOF scalar inversions must be

>>>> replaced by the inverse of a linear N-DOF system. For example, a mobile

>>>> platform is _not_ a serial P-P-R joint, but really a Nx3 (N>=3) joint,

>>>> with

>>>> N motors driving 3 mechanical DOFs.

>>> Good example.

>>>

>>> The non-holonomicity of the example leaves me confused on the what

>>> interface (methods/properties) the Joint data structure should have.

>>

>> It does not make much sense, really, _because_ of the

>> non-holonomicity. In

>> other words, the joint values are _not_ a faithful representation of the

>> state of the mobile platform.

>>

>>> Currently it has:

>>> Frame Pos( double q) const

>>> Twist Twist( double qdot) const

>>>

>>> and some introspection methods

>>>

>>> Which is clearly not sufficient for a general joint,

>>> (1) A 1-dof joint could have, in pseudo-code:

>>> Frame Pos(double q) const

>>> Twist Twist(double q, double qdot) const

>>> Twist AccelerationTwist(double q,double qdot, double qdotdot) const

>>

>> Yes.

>>

>>> (2) If we extend this to N-dof holonomic, this becomes in pseudo-code:

>>> Frame Pos(doubleArray q) const

>>> Twist Twist(doubleArray q, doubleArray qdot) const

>>> Twist AccelerationTwist(doubleArray q, doubleArray qdot, doubleArray

>>> qdotdot) const

>>> Matrix Jacobian(doubleArray q) const

>>> Matrix JacobianDerivative(doubleArray q,doubleArray qdot) const

>>

>> "N-dof holonomic" _is_ a kinematic chain, so I would not introduce a

>> separate primitive for it.

> So the same conclusion is reached as in my original remark: the N-dof

> holonomic case is captured by the "Chain" concept,

> and no N-dof should be introduced.

>

> Gianni, did you had other use cases for N-dof joints ?

I suggested before the spherical joint, that is (in my opinion, Erwin

disagrees) that is not suited to be represented as serial kinematic

chain, since it has no singularity.

On the other hand, i would say that is a way to include parallel

kinematics, e.g. articulated parallelogram, (Bert robot's): i treated it

as an equivalent serial kinematic chain (because the transformation is

very easy), but in reality it has two actuated joints, and you need to

know the position of both to understand where the end effector is, and

with out both is not possible to compute even partial infos...

Or there are other way already implement to automatically solve these

kinematics?

>

>>

>>> As you can see, I added some Jacobian/JacobianDerivative functions in

>>> this case. For the 1-dof case these methods were trivially equivalent

>>> to the

>>> Twist and AccelerationTwist.

>>

>> Indeed.

>>

>>> I do not yet consider which twist/acc. twist we are going to use.

>>>

>>> (3) But for the N-dof non-holonomic case of the above example, I do

>>> not know what would be our definition of the Joint class ??

>>

>> It does not make real sense, since the joint value is _not_ a state

>> parameter. Pos and Jacobian of a non-holonomic system are dependent on

>> the

>> _Cartesian_ state (which is really a state) and the change in joint

>> angles.

> Conclusion: We do not consider these non-holonomic cases in the

> modelling of the Chain/Joints. It is modelled

> outside these concepts.

>

>>

>>> If we do not have such a N-dof non-holonomic joint, how can we

>>> represent the above example in KDL or above KDL

>>> (e.g. with a massless P-P-R serial joint, together with differential

>>> constraints) ?

>>

>> KDL can currently not represent such systems faithfully.

>>

>>> Note on the side:

>>> in Ruben's implementation we have inertia,damping, stiffness

>>> specified in the constructors for the joints,

>>> but there is no way that these properties are ever used, because it

>>> is not exposed (explicitly or implicitly) outside the

>>> Joint class. Does somebody knows the reasoning behind this ?

>>

>> The reasoning was okay (dynamics _is_ useful), but the implementation was

>> wrong: too much information hiding :-)

>>

>>> Does a Joint by itself contains dynamics ? Or should the dynamics

>>> only be represented by the Segment class ?

>>

>> I am advocating since quite some time (and it was in the original

>> _design_

>> of KDL that I made with Ruben) to introduce the extra classes of

>> "Actuator"

>> (which has actuation dynamics, possibly mechanical, but also electrical,

>> pneumatic,...) and "Transmission" (which has the mechanical dynamics you

>> mention) and let the "Joint" represent the purely kinematic, ideal

>> concept.

>>

>

>> Herman

>

## [Bug 967] Using path-like specification to create joints

On Wed, 13 Jun 2012, Gianni Borghesan wrote:

[...]

>> > "N-dof holonomic" _is_ a kinematic chain, so I would not introduce a

>> > separate primitive for it.

>> So the same conclusion is reached as in my original remark: the N-dof

>> holonomic case is captured by the "Chain" concept,

>> and no N-dof should be introduced.

>>

>> Gianni, did you had other use cases for N-dof joints ?

>

> I suggested before the spherical joint, that is (in my opinion, Erwin

> disagrees) that is not suited to be represented as serial kinematic chain,

> since it has no singularity.

Agreed. The (very few) _actuated_ versions of spherical joints that I have

seen do not have serial chain _actuators_ either.

> On the other hand, i would say that is a way to include parallel kinematics,

> e.g. articulated parallelogram, (Bert robot's): i treated it as an equivalent

> serial kinematic chain (because the transformation is very easy), but in

> reality it has two actuated joints, and you need to know the position of both

> to understand where the end effector is, and with out both is not possible to

> compute even partial infos...

These are so-called "hybrid" kinematic chains, which have a _graph_

topology, in contrast to the serial and tree topologies that KDL currently

supports.

I am in favour of adding these things to KDL. A lot. But again, not without

thorough design discussions.

My one-line "design document" in this context: "solving" a hybrid chain is

done in different phases:

1. (instantaneously) finding a "spanning tree" over the topological graph;

2. solving the tree, as a first approximation of the hybrid case;

3. iterate until this approximation has reached the configured tolerance.

(Side note: this is _exactly_ the same design for, for example,

general/hybrid Bayesian networks, general control diagrams, etc. So, I

would like to see a lot of code reuse, over all these use cases.)

> Or there are other way already implement to automatically solve these

> kinematics?

No. (Unless you go to closed source tools, where lots of solvers exist

already.)

Herman

## [Bug 967] Using path-like specification to create joints

On 06/13/2012 05:05 PM, Herman Bruyninckx wrote:

> On Wed, 13 Jun 2012, Gianni Borghesan wrote:

>

> [...]

>>> > "N-dof holonomic" _is_ a kinematic chain, so I would not introduce a

>>> > separate primitive for it.

>>> So the same conclusion is reached as in my original remark: the N-dof

>>> holonomic case is captured by the "Chain" concept,

>>> and no N-dof should be introduced.

>>>

>>> Gianni, did you had other use cases for N-dof joints ?

>>

>> I suggested before the spherical joint, that is (in my opinion, Erwin

>> disagrees) that is not suited to be represented as serial kinematic

>> chain, since it has no singularity.

>

> Agreed. The (very few) _actuated_ versions of spherical joints that I have

> seen do not have serial chain _actuators_ either.

actually, i was thinking more to virtual kinematic chains for the

spherical joints use.

>

>> On the other hand, i would say that is a way to include parallel

>> kinematics, e.g. articulated parallelogram, (Bert robot's): i treated

>> it as an equivalent serial kinematic chain (because the transformation

>> is very easy), but in reality it has two actuated joints, and you need

>> to know the position of both to understand where the end effector is,

>> and with out both is not possible to compute even partial infos...

>

> These are so-called "hybrid" kinematic chains, which have a _graph_

> topology, in contrast to the serial and tree topologies that KDL currently

> supports.

>

what i was suggesting, is that the programmer encapsulate part of the

graph in a single joint, so that the chain comes back to serial/tree

it is an analytical, ad hoc solution for each case...

> I am in favour of adding these things to KDL. A lot. But again, not without

> thorough design discussions.

>

> My one-line "design document" in this context: "solving" a hybrid chain is

> done in different phases:

> 1. (instantaneously) finding a "spanning tree" over the topological graph;

> 2. solving the tree, as a first approximation of the hybrid case;

> 3. iterate until this approximation has reached the configured tolerance.

>

> (Side note: this is _exactly_ the same design for, for example,

> general/hybrid Bayesian networks, general control diagrams, etc. So, I

> would like to see a lot of code reuse, over all these use cases.)

>

>> Or there are other way already implement to automatically solve these

>> kinematics?

>

> No. (Unless you go to closed source tools, where lots of solvers exist

> already.)

>

> Herman

## [Bug 967] Using path-like specification to create joints

On 06/13/2012 04:34 PM, Gianni Borghesan wrote:

>

>

> On 06/13/2012 04:07 PM, Erwin Aertbelien wrote:

>> On 06/13/2012 03:50 PM, Herman Bruyninckx wrote:

>>> On Wed, 13 Jun 2012, Erwin Aertbelien wrote:

>>>

>>> [...]

>>>>> > > I do agree with the addition of N-DOF joints, such as spherical

>>>>> ones, > > or

>>>>> > > mobile

>>>>> > > bases, etc.

>>>>> > > > But what is the difference between an N-dof joint and a robot ?

>>>>> > And what to do with the dynamics.

>>>>>

>>>>> I answer two remarks at the same time, because they _are_

>>>>> intrinsically

>>>>> linked: an N-dof joint _must_ have an N-dof dynamics algorithm,

>>>>> and not

>>>>> the

>>>>> N-times-1 unphysical models that people are typically using. More

>>>>> concretely, in the inverse dynamics the 1-DOF scalar inversions

>>>>> must be

>>>>> replaced by the inverse of a linear N-DOF system. For example, a

>>>>> mobile

>>>>> platform is _not_ a serial P-P-R joint, but really a Nx3 (N>=3)

>>>>> joint,

>>>>> with

>>>>> N motors driving 3 mechanical DOFs.

>>>> Good example.

>>>>

>>>> The non-holonomicity of the example leaves me confused on the what

>>>> interface (methods/properties) the Joint data structure should have.

>>>

>>> It does not make much sense, really, _because_ of the

>>> non-holonomicity. In

>>> other words, the joint values are _not_ a faithful representation of

>>> the

>>> state of the mobile platform.

>>>

>>>> Currently it has:

>>>> Frame Pos( double q) const

>>>> Twist Twist( double qdot) const

>>>>

>>>> and some introspection methods

>>>>

>>>> Which is clearly not sufficient for a general joint,

>>>> (1) A 1-dof joint could have, in pseudo-code:

>>>> Frame Pos(double q) const

>>>> Twist Twist(double q, double qdot) const

>>>> Twist AccelerationTwist(double q,double qdot, double qdotdot) const

>>>

>>> Yes.

>>>

>>>> (2) If we extend this to N-dof holonomic, this becomes in pseudo-code:

>>>> Frame Pos(doubleArray q) const

>>>> Twist Twist(doubleArray q, doubleArray qdot) const

>>>> Twist AccelerationTwist(doubleArray q, doubleArray qdot, doubleArray

>>>> qdotdot) const

>>>> Matrix Jacobian(doubleArray q) const

>>>> Matrix JacobianDerivative(doubleArray q,doubleArray qdot) const

>>>

>>> "N-dof holonomic" _is_ a kinematic chain, so I would not introduce a

>>> separate primitive for it.

>> So the same conclusion is reached as in my original remark: the N-dof

>> holonomic case is captured by the "Chain" concept,

>> and no N-dof should be introduced.

>>

>> Gianni, did you had other use cases for N-dof joints ?

>

> I suggested before the spherical joint, that is (in my opinion, Erwin

> disagrees)

I disagree in the sense that, even with N-dof holonomic, I would not

know how to handle a spherical joint in a Chain without introducing

algorithmic singularities.

( in the constraint-resolution level this can be done, but not at the

level of a kinematic chain, nor at the level of iTasc).

( you will need to introduce a redundant parametrization, but these come

with additional constraints between the redundant

parameters, that limit the usage of the resulting kinematic chain ).

( otherwise said, whatever you do, the rotational velocities are

non-integrable).

And with regards to a roll-pitch-yaw(alpha,beta,gamma) parametrized

spherical joint, you can build an equivalent EulerZYX(gamma,beta,alpha)

kinematic

chain.

> that is not suited to be represented as serial kinematic chain, since

> it has no singularity.

> On the other hand, i would say that is a way to include parallel

> kinematics, e.g. articulated parallelogram, (Bert robot's): i treated

> it as an equivalent serial kinematic chain (because the transformation

> is very easy), but in reality it has two actuated joints, and you need

> to know the position of both to understand where the end effector is,

> and with out both is not possible to compute even partial infos...

Isn't this not only necessary when you take dynamics into account ? or

is it also kinematically necessary ?

Would the N-dof holonomic (with the given interface) improve the situation ?

But your example reminds me of something else that commonly occurs:

because of the way motions are transmitted from the motor to the

physical joints, there is a

coupling between the physical joints.

in other words: the relation between motor angles and physical joint

angles is given by a non-diagonal matrix.

Currently such things are not modelled within KDL. People tend to

work with the physical joint values and

then only translate it in a last step (outside KDL) when

writing/reading it to/from the robot interface.

The Joint/Actuator/Transmission proposal I made in the other mail

cannot handle this.

> Or there are other way already implement to automatically solve these

> kinematics?

>

>

>>

>>>

>>>> As you can see, I added some Jacobian/JacobianDerivative functions in

>>>> this case. For the 1-dof case these methods were trivially equivalent

>>>> to the

>>>> Twist and AccelerationTwist.

>>>

>>> Indeed.

>>>

>>>> I do not yet consider which twist/acc. twist we are going to use.

>>>>

>>>> (3) But for the N-dof non-holonomic case of the above example, I do

>>>> not know what would be our definition of the Joint class ??

>>>

>>> It does not make real sense, since the joint value is _not_ a state

>>> parameter. Pos and Jacobian of a non-holonomic system are dependent on

>>> the

>>> _Cartesian_ state (which is really a state) and the change in joint

>>> angles.

>> Conclusion: We do not consider these non-holonomic cases in the

>> modelling of the Chain/Joints. It is modelled

>> outside these concepts.

>>

>>>

>>>> If we do not have such a N-dof non-holonomic joint, how can we

>>>> represent the above example in KDL or above KDL

>>>> (e.g. with a massless P-P-R serial joint, together with differential

>>>> constraints) ?

>>>

>>> KDL can currently not represent such systems faithfully.

>>>

>>>> Note on the side:

>>>> in Ruben's implementation we have inertia,damping, stiffness

>>>> specified in the constructors for the joints,

>>>> but there is no way that these properties are ever used, because it

>>>> is not exposed (explicitly or implicitly) outside the

>>>> Joint class. Does somebody knows the reasoning behind this ?

>>>

>>> The reasoning was okay (dynamics _is_ useful), but the

>>> implementation was

>>> wrong: too much information hiding :-)

>>>

>>>> Does a Joint by itself contains dynamics ? Or should the dynamics

>>>> only be represented by the Segment class ?

>>>

>>> I am advocating since quite some time (and it was in the original

>>> _design_

>>> of KDL that I made with Ruben) to introduce the extra classes of

>>> "Actuator"

>>> (which has actuation dynamics, possibly mechanical, but also

>>> electrical,

>>> pneumatic,...) and "Transmission" (which has the mechanical dynamics

>>> you

>>> mention) and let the "Joint" represent the purely kinematic, ideal

>>> concept.

>>>

>>

>>> Herman

>>

>

## [Bug 967] Using path-like specification to create joints

On Wed, 13 Jun 2012, Erwin Aertbelien wrote:

> On 06/13/2012 04:34 PM, Gianni Borghesan wrote:

>>

>>

>> On 06/13/2012 04:07 PM, Erwin Aertbelien wrote:

>> > On 06/13/2012 03:50 PM, Herman Bruyninckx wrote:

>> > > On Wed, 13 Jun 2012, Erwin Aertbelien wrote:

>> > >

>> > > [...]

>> > > > > > > I do agree with the addition of N-DOF joints, such as

>> > > > > > > spherical

>> > > > > ones, > > or

>> > > > > > > mobile

>> > > > > > > bases, etc.

>> > > > > > > > But what is the difference between an N-dof joint and a

>> > > > > > > > robot ?

>> > > > > > And what to do with the dynamics.

>> > > > >

>> > > > > I answer two remarks at the same time, because they _are_

>> > > > > intrinsically

>> > > > > linked: an N-dof joint _must_ have an N-dof dynamics algorithm,

>> > > > > and not

>> > > > > the

>> > > > > N-times-1 unphysical models that people are typically using. More

>> > > > > concretely, in the inverse dynamics the 1-DOF scalar inversions

>> > > > > must be

>> > > > > replaced by the inverse of a linear N-DOF system. For example, a

>> > > > > mobile

>> > > > > platform is _not_ a serial P-P-R joint, but really a Nx3 (N>=3)

>> > > > > joint,

>> > > > > with

>> > > > > N motors driving 3 mechanical DOFs.

>> > > > Good example.

>> > > >

>> > > > The non-holonomicity of the example leaves me confused on the what

>> > > > interface (methods/properties) the Joint data structure should have.

>> > >

>> > > It does not make much sense, really, _because_ of the

>> > > non-holonomicity. In

>> > > other words, the joint values are _not_ a faithful representation of

>> > > the

>> > > state of the mobile platform.

>> > >

>> > > > Currently it has:

>> > > > Frame Pos( double q) const

>> > > > Twist Twist( double qdot) const

>> > > >

>> > > > and some introspection methods

>> > > >

>> > > > Which is clearly not sufficient for a general joint,

>> > > > (1) A 1-dof joint could have, in pseudo-code:

>> > > > Frame Pos(double q) const

>> > > > Twist Twist(double q, double qdot) const

>> > > > Twist AccelerationTwist(double q,double qdot, double qdotdot) const

>> > >

>> > > Yes.

>> > >

>> > > > (2) If we extend this to N-dof holonomic, this becomes in

>> > > > pseudo-code:

>> > > > Frame Pos(doubleArray q) const

>> > > > Twist Twist(doubleArray q, doubleArray qdot) const

>> > > > Twist AccelerationTwist(doubleArray q, doubleArray qdot, doubleArray

>> > > > qdotdot) const

>> > > > Matrix Jacobian(doubleArray q) const

>> > > > Matrix JacobianDerivative(doubleArray q,doubleArray qdot) const

>> > >

>> > > "N-dof holonomic" _is_ a kinematic chain, so I would not introduce a

>> > > separate primitive for it.

>> > So the same conclusion is reached as in my original remark: the N-dof

>> > holonomic case is captured by the "Chain" concept,

>> > and no N-dof should be introduced.

>> >

>> > Gianni, did you had other use cases for N-dof joints ?

>>

>> I suggested before the spherical joint, that is (in my opinion, Erwin

>> disagrees)

> I disagree in the sense that, even with N-dof holonomic, I would not know

> how to handle a spherical joint in a Chain without introducing

> algorithmic singularities.

>

Agreed.

> ( in the constraint-resolution level this can be done, but not at the level

> of a kinematic chain, nor at the level of iTasc).

Agreed.

> ( you will need to introduce a redundant parametrization, but these come with

> additional constraints between the redundant

> parameters, that limit the usage of the resulting kinematic chain ).

> ( otherwise said, whatever you do, the rotational velocities are

> non-integrable).

Well, they _are_, but not without (well known) integration factors.

> And with regards to a roll-pitch-yaw(alpha,beta,gamma) parametrized spherical

> joint, you can build an equivalent EulerZYX(gamma,beta,alpha) kinematic

> chain.

Agreed.

>> that is not suited to be represented as serial kinematic chain, since it

>> has no singularity.

>> On the other hand, i would say that is a way to include parallel

>> kinematics, e.g. articulated parallelogram, (Bert robot's): i treated it

>> as an equivalent serial kinematic chain (because the transformation is

>> very easy), but in reality it has two actuated joints, and you need to

>> know the position of both to understand where the end effector is, and

>> with out both is not possible to compute even partial infos...

> Isn't this not only necessary when you take dynamics into account ? or is it

> also kinematically necessary ?

For _general_ hybrid chains, it is necessary also at the kinematic level.

> Would the N-dof holonomic (with the given interface) improve the situation ?

No idea...

> But your example reminds me of something else that commonly occurs:

> because of the way motions are transmitted from the motor to the physical

> joints, there is a coupling between the physical joints.

Indeed. Hence I think there is room for a "Transmission" class (or rahter,

family of classes) that represents this reality.

> in other words: the relation between motor angles and physical joint

> angles is given by a non-diagonal matrix.

> Currently such things are not modelled within KDL. People tend to work

> with the physical joint values and

> then only translate it in a last step (outside KDL) when writing/reading

> it to/from the robot interface.

Yes. Because there is no dedicated "Transmission" class.

> The Joint/Actuator/Transmission proposal I made in the other mail cannot

> handle this.

Not your current version; but a slightly extended one can, as I hope I

could convey in my emails.

Herman

## [Bug 967] Using path-like specification to create joints

On 06/13/2012 05:10 PM, Herman Bruyninckx wrote:

> On Wed, 13 Jun 2012, Erwin Aertbelien wrote:

>

>> On 06/13/2012 04:34 PM, Gianni Borghesan wrote:

>>>

>>>

>>> On 06/13/2012 04:07 PM, Erwin Aertbelien wrote:

>>> > On 06/13/2012 03:50 PM, Herman Bruyninckx wrote:

>>> > > On Wed, 13 Jun 2012, Erwin Aertbelien wrote:

>>> > > > > [...]

>>> > > > > > > I do agree with the addition of N-DOF joints, such as >

>>> > > > > > spherical

>>> > > > > ones, > > or

>>> > > > > > > mobile

>>> > > > > > > bases, etc.

>>> > > > > > > > But what is the difference between an N-dof joint and

>>> a > > > > > > > robot ?

>>> > > > > > And what to do with the dynamics.

>>> > > > > > > > > I answer two remarks at the same time, because they

>>> _are_ > > > > intrinsically

>>> > > > > linked: an N-dof joint _must_ have an N-dof dynamics

>>> algorithm, > > > > and not

>>> > > > > the

>>> > > > > N-times-1 unphysical models that people are typically

>>> using. More

>>> > > > > concretely, in the inverse dynamics the 1-DOF scalar

>>> inversions > > > > must be

>>> > > > > replaced by the inverse of a linear N-DOF system. For

>>> example, a > > > > mobile

>>> > > > > platform is _not_ a serial P-P-R joint, but really a Nx3

>>> (N>=3) > > > > joint,

>>> > > > > with

>>> > > > > N motors driving 3 mechanical DOFs.

>>> > > > Good example.

>>> > > > > > > The non-holonomicity of the example leaves me confused

>>> on the what

>>> > > > interface (methods/properties) the Joint data structure

>>> should have.

>>> > > > > It does not make much sense, really, _because_ of the

>>> > > non-holonomicity. In

>>> > > other words, the joint values are _not_ a faithful

>>> representation of > > the

>>> > > state of the mobile platform.

>>> > > > > > Currently it has:

>>> > > > Frame Pos( double q) const

>>> > > > Twist Twist( double qdot) const

>>> > > > > > > and some introspection methods

>>> > > > > > > Which is clearly not sufficient for a general joint,

>>> > > > (1) A 1-dof joint could have, in pseudo-code:

>>> > > > Frame Pos(double q) const

>>> > > > Twist Twist(double q, double qdot) const

>>> > > > Twist AccelerationTwist(double q,double qdot, double qdotdot)

>>> const

>>> > > > > Yes.

>>> > > > > > (2) If we extend this to N-dof holonomic, this becomes in

>>> > > > pseudo-code:

>>> > > > Frame Pos(doubleArray q) const

>>> > > > Twist Twist(doubleArray q, doubleArray qdot) const

>>> > > > Twist AccelerationTwist(doubleArray q, doubleArray qdot,

>>> doubleArray

>>> > > > qdotdot) const

>>> > > > Matrix Jacobian(doubleArray q) const

>>> > > > Matrix JacobianDerivative(doubleArray q,doubleArray qdot) const

>>> > > > > "N-dof holonomic" _is_ a kinematic chain, so I would not

>>> introduce a

>>> > > separate primitive for it.

>>> > So the same conclusion is reached as in my original remark: the

>>> N-dof

>>> > holonomic case is captured by the "Chain" concept,

>>> > and no N-dof should be introduced.

>>> > > Gianni, did you had other use cases for N-dof joints ?

>>>

>>> I suggested before the spherical joint, that is (in my opinion, Erwin

>>> disagrees)

>> I disagree in the sense that, even with N-dof holonomic, I would not

>> know how to handle a spherical joint in a Chain without introducing

>> algorithmic singularities.

>>

> Agreed.

>

>> ( in the constraint-resolution level this can be done, but not at the

>> level of a kinematic chain, nor at the level of iTasc).

>

> Agreed.

>

>> ( you will need to introduce a redundant parametrization, but these

>> come with additional constraints between the redundant

>> parameters, that limit the usage of the resulting kinematic chain ).

>> ( otherwise said, whatever you do, the rotational velocities are

>> non-integrable).

>

> Well, they _are_, but not without (well known) integration factors.

I meant, integrable in the sense of integrable systems, i.e. there

exists a function of which the rotational velocities are the derivatives

in the whole domain under consideration.

Because the integration factors can become singular, these derivatives

not always exists.

(closely related to non-holonomicity)

*

*

>

>> And with regards to a roll-pitch-yaw(alpha,beta,gamma) parametrized

>> spherical joint, you can build an equivalent

>> EulerZYX(gamma,beta,alpha) kinematic

>> chain.

>

> Agreed.

>

>>> that is not suited to be represented as serial kinematic chain,

>>> since it

>>> has no singularity.

>>> On the other hand, i would say that is a way to include parallel

>>> kinematics, e.g. articulated parallelogram, (Bert robot's): i

>>> treated it

>>> as an equivalent serial kinematic chain (because the transformation is

>>> very easy), but in reality it has two actuated joints, and you need to

>>> know the position of both to understand where the end effector is, and

>>> with out both is not possible to compute even partial infos...

>

>> Isn't this not only necessary when you take dynamics into account ?

>> or is it also kinematically necessary ?

>

> For _general_ hybrid chains, it is necessary also at the kinematic level.

>

>> Would the N-dof holonomic (with the given interface) improve the

>> situation ?

> No idea...

>

>> But your example reminds me of something else that commonly occurs:

>> because of the way motions are transmitted from the motor to the

>> physical joints, there is a coupling between the physical joints.

>

> Indeed. Hence I think there is room for a "Transmission" class (or

> rahter,

> family of classes) that represents this reality.

>

>> in other words: the relation between motor angles and physical

>> joint angles is given by a non-diagonal matrix.

>> Currently such things are not modelled within KDL. People tend to

>> work with the physical joint values and

>> then only translate it in a last step (outside KDL) when

>> writing/reading it to/from the robot interface.

>

> Yes. Because there is no dedicated "Transmission" class.

>

>> The Joint/Actuator/Transmission proposal I made in the other mail

>> cannot handle this.

>

> Not your current version; but a slightly extended one can, as I hope I

> could convey in my emails.

>

> Herman

## [Bug 967] Using path-like specification to create joints

On Wed, 13 Jun 2012, Erwin Aertbelien wrote:

[...]

>> > I disagree in the sense that, even with N-dof holonomic, I would not

>> > know how to handle a spherical joint in a Chain without introducing

>> > algorithmic singularities.

>> >

>> Agreed.

>>

>> > ( in the constraint-resolution level this can be done, but not at the

>> > level of a kinematic chain, nor at the level of iTasc).

>>

>> Agreed.

>>

>> > ( you will need to introduce a redundant parametrization, but these come

>> > with additional constraints between the redundant

>> > parameters, that limit the usage of the resulting kinematic chain ).

>> > ( otherwise said, whatever you do, the rotational velocities are

>> > non-integrable).

>>

>> Well, they _are_, but not without (well known) integration factors.

> I meant, integrable in the sense of integrable systems, i.e. there exists a

> function of which the rotational velocities are the derivatives in the whole

> domain under consideration.

> Because the integration factors can become singular, these derivatives not

> always exists.

> (closely related to non-holonomicity)

_Identical_ to non-holonomicity :-) At least, if you go back to the history of

integration on manifolds, as pioneered by Sophus Lie and colleagues...

Herman