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