proposal to solve inconsistency in KDL types (only the geometric primitives)
| Submitted by Tinne De Laet on Tue, 2012-11-20 15:15 |
Hey KDL-users,
The KDL types ("Geometric primitives and their transformations:
KDL::Vector, KDL::Rotation, KDL::Frame, KDL::Twist, KDL::Wrench) are
somewhat inconsistent. Some represent data types while others are real
coordinate representations.
Example:
1) KDL::Vector is a "A concrete implementation of a 3 dimensional vector
class". It can represent a position vector, a linear velocity vector, an
angular velocity vector, a force vector, a torque vector, ...
2) KDL::Rotation, KDL::Frame, KDL::Twist and KDL::Wrench represent a 3x3
rotation matrix, a 4x4 homogeneous transformation matrix, a 6x1 twist
vector, and a 6x1 wrench vector, respetively.
As a proposal I would suggest to introduce extra types (which can
inherit from KDL::Vector)
* KDL::PositionVector
* KDL::LinearVelocityVector
* KDL::AngularVelocityVector
* KDL::ForceVector
* KDL::TorqueVector
This is the basic idea of the proposed change. I believe it will not be
very intrusive.
Nevertheless, if we push this idea to its limits it will probably cause
an API break
For instance: The constructor Frame (const Rotation &R, const Vector &V)
will be replaced by Frame (const Rotation &R, const PositionVector &V)
Any feedback is welcome.
Tinne
proposal to solve inconsistency in KDL types (only the geometric
On Tue, 20 Nov 2012, Tinne De Laet wrote:
> Hey KDL-users,
>
> The KDL types ("Geometric primitives and their transformations:
> KDL::Vector, KDL::Rotation, KDL::Frame, KDL::Twist, KDL::Wrench) are
> somewhat inconsistent. Some represent data types while others are real
> coordinate representations.
>
> Example:
> 1) KDL::Vector is a "A concrete implementation of a 3 dimensional vector
> class". It can represent a position vector, a linear velocity vector, an
> angular velocity vector, a force vector, a torque vector, ...
> 2) KDL::Rotation, KDL::Frame, KDL::Twist and KDL::Wrench represent a 3x3
> rotation matrix, a 4x4 homogeneous transformation matrix, a 6x1 twist
> vector, and a 6x1 wrench vector, respetively.
>
> As a proposal I would suggest to introduce extra types (which can
> inherit from KDL::Vector)
> * KDL::PositionVector
> * KDL::LinearVelocityVector
> * KDL::AngularVelocityVector
> * KDL::ForceVector
> * KDL::TorqueVector
>
>
> This is the basic idea of the proposed change. I believe it will not be
> very intrusive.
> Nevertheless, if we push this idea to its limits it will probably cause
> an API break
> For instance: The constructor Frame (const Rotation &R, const Vector &V)
> will be replaced by Frame (const Rotation &R, const PositionVector &V)
>
>
> Any feedback is welcome.
I am all for adding correct semantics to the whole process of robot
software development, but _not_ in C++ code. My position is that:
- semantics must be added to _models_ (in DSLs, not in C++)
- the code should be optimized for execution performance, not for semantic
correctness
- code should be _generated_, not written.
Of course, these goals are not reached in one day, but the suggested
changes are a step in the wrong direction, in my opinion.
I think KDL should become the most efficient solver library out there, and
not just to run on with an operation system or a software framework as
basis, but also on "bare metal" such as FPGAs. This implies moving "back"
to C, instead of to more C++. (But always in the context of having semantic
model on top of the code, of course.)
> Tinne
Herman
proposal to solve inconsistency in KDL types (only the geometric
On 11/21/2012 07:27 AM, Herman Bruyninckx wrote:
>
> Any feedback is welcome.
> I am all for adding correct semantics to the whole process of robot
> software development, but _not_ in C++ code. My position is that:
> - semantics must be added to _models_ (in DSLs, not in C++)
> - the code should be optimized for execution performance, not for semantic
> correctness
> - code should be _generated_, not written.
> Of course, these goals are not reached in one day, but the suggested
> changes are a step in the wrong direction, in my opinion.
>
> I think KDL should become the most efficient solver library out there, and
> not just to run on with an operation system or a software framework as
> basis, but also on "bare metal" such as FPGAs. This implies moving "back"
> to C, instead of to more C++. (But always in the context of having semantic
> model on top of the code, of course.)
I don't agree. (Surprised ?)
First KDL is C++ and the changes that Tinne proposes are non-intrusive
proposal to solve inconsistency in KDL types (only the geometric
On Nov 21, 2012, at 03:52 , Sylvain Joyeux wrote:
> On 11/21/2012 07:27 AM, Herman Bruyninckx wrote:
>>
>> Any feedback is welcome.
>> I am all for adding correct semantics to the whole process of robot
>> software development, but _not_ in C++ code. My position is that:
>> - semantics must be added to _models_ (in DSLs, not in C++)
>> - the code should be optimized for execution performance, not for semantic
>> correctness
>> - code should be _generated_, not written.
>> Of course, these goals are not reached in one day, but the suggested
>> changes are a step in the wrong direction, in my opinion.
>>
>> I think KDL should become the most efficient solver library out there, and
>> not just to run on with an operation system or a software framework as
>> basis, but also on "bare metal" such as FPGAs. This implies moving "back"
>> to C, instead of to more C++. (But always in the context of having semantic
>> model on top of the code, of course.)
> I don't agree. (Surprised ?)
>
> First KDL is C++ and the changes that Tinne proposes are non-intrusive
proposal to solve inconsistency in KDL types (only the geometric
On Wed, 21 Nov 2012, Sylvain Joyeux wrote:
> On 11/21/2012 07:27 AM, Herman Bruyninckx wrote:
>>
>> Any feedback is welcome.
>> I am all for adding correct semantics to the whole process of robot
>> software development, but _not_ in C++ code. My position is that:
>> - semantics must be added to _models_ (in DSLs, not in C++)
>> - the code should be optimized for execution performance, not for semantic
>> correctness
>> - code should be _generated_, not written.
>> Of course, these goals are not reached in one day, but the suggested
>> changes are a step in the wrong direction, in my opinion.
>>
>> I think KDL should become the most efficient solver library out there, and
>> not just to run on with an operation system or a software framework as
>> basis, but also on "bare metal" such as FPGAs. This implies moving "back"
>> to C, instead of to more C++. (But always in the context of having semantic
>> model on top of the code, of course.)
> I don't agree. (Surprised ?)
Sure! :-)
> First KDL is C++
It is using a very limited set of C++ (by design), which is very close to C
anyway. Only the template stuff is bothering me, because templates are the
C++ way of doing model-driven engineering, with a high lock-in into the
language.
> and the changes that Tinne proposes are non-intrusive --
> i.e. don't make the code to be instanciated more complex, just use more of
> the type system to achieve some safety at the C++ level.
Exactly. But adding more type safety results in more effort. Again, I think
this effort is best put in making models on top of the code, to deal with
the semantics (= more than just type checking).
> For what it is worth, the changes she proposes are in line with a course I
> once had from a Pixar software engineer. They do separate for instance point
> and vector, and e.g. don't allow point + point.
I am all for avoiding such mistakes. However, robotics (and, yes, the very
related domain of computer animation) is not very "model driven", so the
best one can achieve there is adding semantics via templates and type
checking. I know of many domains that do not take this approach, and where
the semantic checks are in the models and the code is "generated pure C".
> The part I don't like about her proposal is the absence of backward
> compatibility, which would not be hard to get (subclass each "sematically
> correct" Vector subtype from Vector and give both versions of the methods).
> It would allow to gradually move to a more type-checked version of the
> library, which is IMO a good thing.
Backward compatibility is always a good thing, for incremental changes.
Dealing 100% with correct semantics will probably require non-incremental
changes. Hence, another "library" independent from KDL...?
This is an important "forking" decision: I have no problem with such a
fork, because it is not really a fork but a friendly evolution towards two
different goals.
> Sylvain Joyeux (Dr.Ing.)
Herman
> Senior Researcher
>
> Space & Security Robotics
> Underwater Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> Weitere Informationen: http://www.dfki.de/robotik
> -----------------------------------------------------------------------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973
> Steuernummer: 19/673/0060/3
> -----------------------------------------------------------------------
>
>
--
KU Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
Vice-President Research euRobotics <http://www.eu-robotics.net>
Open RObot COntrol Software <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
proposal to solve inconsistency in KDL types (only the geometric
On Wed, Nov 21, 2012 at 10:07 AM, Herman Bruyninckx
<Herman [dot] Bruyninckx [..] ...> wrote:
> On Wed, 21 Nov 2012, Sylvain Joyeux wrote:
>
>> On 11/21/2012 07:27 AM, Herman Bruyninckx wrote:
>>>
>>>
>>> Any feedback is welcome.
>>> I am all for adding correct semantics to the whole process of robot
>>> software development, but _not_ in C++ code. My position is that:
>>> - semantics must be added to _models_ (in DSLs, not in C++)
>>> - the code should be optimized for execution performance, not for
>>> semantic
>>> correctness
>>> - code should be _generated_, not written.
>>> Of course, these goals are not reached in one day, but the suggested
>>> changes are a step in the wrong direction, in my opinion.
>>>
>>> I think KDL should become the most efficient solver library out there,
>>> and
>>> not just to run on with an operation system or a software framework as
>>> basis, but also on "bare metal" such as FPGAs. This implies moving "back"
>>> to C, instead of to more C++. (But always in the context of having
>>> semantic
>>> model on top of the code, of course.)
>>
>> I don't agree. (Surprised ?)
>
>
> Sure! :-)
>
>> First KDL is C++
>
>
> It is using a very limited set of C++ (by design), which is very close to C
> anyway. Only the template stuff is bothering me, because templates are the
> C++ way of doing model-driven engineering, with a high lock-in into the
> language.
>
The only templates in KDL are due to the use of STL types. So would
suggest to take a step back and not use these and redo all that we use
from this library in plain C?
>
>> and the changes that Tinne proposes are non-intrusive -- i.e. don't make
>> the code to be instanciated more complex, just use more of the type system
>> to achieve some safety at the C++ level.
>
>
> Exactly. But adding more type safety results in more effort. Again, I think
> this effort is best put in making models on top of the code, to deal with
> the semantics (= more than just type checking).
>
Maybe these models do not belong in KDL (being a code library after all)?
>
>> For what it is worth, the changes she proposes are in line with a course I
>> once had from a Pixar software engineer. They do separate for instance point
>> and vector, and e.g. don't allow point + point.
>
>
> I am all for avoiding such mistakes. However, robotics (and, yes, the very
> related domain of computer animation) is not very "model driven", so the
> best one can achieve there is adding semantics via templates and type
> checking. I know of many domains that do not take this approach, and where
> the semantic checks are in the models and the code is "generated pure C".
>
>
>> The part I don't like about her proposal is the absence of backward
>> compatibility, which would not be hard to get (subclass each "sematically
>> correct" Vector subtype from Vector and give both versions of the methods).
>> It would allow to gradually move to a more type-checked version of the
>> library, which is IMO a good thing.
>
>
> Backward compatibility is always a good thing, for incremental changes.
>
> Dealing 100% with correct semantics will probably require non-incremental
> changes. Hence, another "library" independent from KDL...?
I thought we already had this? Or at least very close to it?
http://www.orocos.org/wiki/geometric-relations-semantics-wiki
Or would you want to take it a step further?
> This is an important "forking" decision: I have no problem with such a
> fork, because it is not really a fork but a friendly evolution towards two
> different goals.
>
>> Sylvain Joyeux (Dr.Ing.)
>
>
> Herman
>
Ruben
>
>> Senior Researcher
>>
>> Space & Security Robotics
>> Underwater Robotics
>>
>> !!! Achtung, neue Telefonnummer!!!
>>
>> Standort Bremen:
>> DFKI GmbH
>> Robotics Innovation Center
>> Robert-Hooke-Straße 5
>> 28359 Bremen, Germany
>>
>> Phone: +49 (0)421 178-454136
>> Fax: +49 (0)421 218-454150
>> E-Mail: robotik [..] ...
>>
>> Weitere Informationen: http://www.dfki.de/robotik
>> -----------------------------------------------------------------------
>> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
>> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
>> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
>> (Vorsitzender) Dr. Walter Olthoff
>> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
>> Amtsgericht Kaiserslautern, HRB 2313
>> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
>> USt-Id.Nr.: DE 148646973
>> Steuernummer: 19/673/0060/3
>> -----------------------------------------------------------------------
>>
>>
>
> --
> KU Leuven, Mechanical Engineering, Robotics Research Group
> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> Vice-President Research euRobotics <http://www.eu-robotics.net>
> Open RObot COntrol Software <http://www.orocos.org>
> Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
proposal to solve inconsistency in KDL types (only the geometric
On Wed, 21 Nov 2012, Ruben Smits wrote:
> On Wed, Nov 21, 2012 at 10:07 AM, Herman Bruyninckx
> <Herman [dot] Bruyninckx [..] ...> wrote:
>> On Wed, 21 Nov 2012, Sylvain Joyeux wrote:
>>
>>> On 11/21/2012 07:27 AM, Herman Bruyninckx wrote:
>>>>
>>>>
>>>> Any feedback is welcome.
>>>> I am all for adding correct semantics to the whole process of robot
>>>> software development, but _not_ in C++ code. My position is that:
>>>> - semantics must be added to _models_ (in DSLs, not in C++)
>>>> - the code should be optimized for execution performance, not for
>>>> semantic
>>>> correctness
>>>> - code should be _generated_, not written.
>>>> Of course, these goals are not reached in one day, but the suggested
>>>> changes are a step in the wrong direction, in my opinion.
>>>>
>>>> I think KDL should become the most efficient solver library out there,
>>>> and
>>>> not just to run on with an operation system or a software framework as
>>>> basis, but also on "bare metal" such as FPGAs. This implies moving "back"
>>>> to C, instead of to more C++. (But always in the context of having
>>>> semantic
>>>> model on top of the code, of course.)
>>>
>>> I don't agree. (Surprised ?)
>>
>>
>> Sure! :-)
>>
>>> First KDL is C++
>>
>>
>> It is using a very limited set of C++ (by design), which is very close to C
>> anyway. Only the template stuff is bothering me, because templates are the
>> C++ way of doing model-driven engineering, with a high lock-in into the
>> language.
>>
>
> The only templates in KDL are due to the use of STL types.
And some Eigen stuff, isn't it?
> So would
> suggest to take a step back and not use these and redo all that we use
> from this library in plain C?
Yes. At least for the specific use case of deployment on accelerated
hardware. As I said, this use case might be so specific that it is too
specific for KDL and will then happen outside of KDL. (That's why I call it
a "friendly fork" :-)). _If_ that happens, it would still be very nice and
useful if both libraries share at least the same "meta model":
documentation, concept terminology, etc.
The problem with the "forked" approach is that it _requires_ some tooling
("model to code" transformations) that are not yet
>>> and the changes that Tinne proposes are non-intrusive -- i.e. don't make
>>> the code to be instanciated more complex, just use more of the type system
>>> to achieve some safety at the C++ level.
>>
>> Exactly. But adding more type safety results in more effort. Again, I think
>> this effort is best put in making models on top of the code, to deal with
>> the semantics (= more than just type checking).
>
> Maybe these models do not belong in KDL (being a code library after all)?
Indeed, I do think this is the best pragmatic approach. The new library
would then best put a fofus on "KDL" as one of the "platforms" for which it
can "generate code" (= fill in the appropriate KDL functions).
>>> For what it is worth, the changes she proposes are in line with a course I
>>> once had from a Pixar software engineer. They do separate for instance point
>>> and vector, and e.g. don't allow point + point.
>>
>> I am all for avoiding such mistakes. However, robotics (and, yes, the very
>> related domain of computer animation) is not very "model driven", so the
>> best one can achieve there is adding semantics via templates and type
>> checking. I know of many domains that do not take this approach, and where
>> the semantic checks are in the models and the code is "generated pure C".
>>
>>
>>> The part I don't like about her proposal is the absence of backward
>>> compatibility, which would not be hard to get (subclass each "sematically
>>> correct" Vector subtype from Vector and give both versions of the methods).
>>> It would allow to gradually move to a more type-checked version of the
>>> library, which is IMO a good thing.
>>
>>
>> Backward compatibility is always a good thing, for incremental changes.
>>
>> Dealing 100% with correct semantics will probably require non-incremental
>> changes. Hence, another "library" independent from KDL...?
>
> I thought we already had this? Or at least very close to it?
> http://www.orocos.org/wiki/geometric-relations-semantics-wiki
> Or would you want to take it a step further?
Yes, more than one step further :-0
The URL points to the first step, which is "only" frames; the next logical
steps are the model/semantics for:
- kinematic chains, and their solvers
- motion specifications (trajectories, itasc,...)
- task specifications (not just motion, but other things like processes
(deburring, painting,...) and user-specific workflows and dialogues
(accepting or not an executed task as "nominal" or "error"),...
Research on all of these extensions is being performed at this moment, in
projects like Rosetta and BRICS and Amarsi; but only the first two steps
are realistic in the time frame of 1-2 years. (And relevant for direct KDL
interaction/integration).
>> This is an important "forking" decision: I have no problem with such a
>> fork, because it is not really a fork but a friendly evolution towards two
>> different goals.
>>
>>> Sylvain Joyeux (Dr.Ing.)
>>
>> Herman
>
> Ruben
Herman
proposal to solve inconsistency in KDL types (only the geometric
On 11/21/2012 09:52 AM, Sylvain Joyeux wrote:
> On 11/21/2012 07:27 AM, Herman Bruyninckx wrote:
>>
>> Any feedback is welcome.
>> I am all for adding correct semantics to the whole process of robot
>> software development, but _not_ in C++ code. My position is that:
>> - semantics must be added to _models_ (in DSLs, not in C++)
>> - the code should be optimized for execution performance, not for
>> semantic
>> correctness
>> - code should be _generated_, not written.
>> Of course, these goals are not reached in one day, but the suggested
>> changes are a step in the wrong direction, in my opinion.
>>
>> I think KDL should become the most efficient solver library out
>> there, and
>> not just to run on with an operation system or a software framework as
>> basis, but also on "bare metal" such as FPGAs. This implies moving
>> "back"
>> to C, instead of to more C++. (But always in the context of having
>> semantic
>> model on top of the code, of course.)
> I don't agree. (Surprised ?)
>
> First KDL is C++ and the changes that Tinne proposes are non-intrusive
proposal to solve inconsistency in KDL types (only the geometric
(sorry for top-posting)
Again, my previous objections remain standing:
- explosion of operations between the different types of Vector that you will introduce.
- the proposed inheritance will only lead to people (both KDL in its own implementation and 3th party)
going back to KDL::Vector. The semantic inconsistencies then only become larger. So, what did we gain ?
- there are some things semantically less clear, but this proposal is not the solution.
Best regards,
Erwin.
________________________________________
From: orocos-users-bounces [..] ... [orocos-users-bounces [..] ...] on behalf of Tinne De Laet [tinne [dot] delaet [..] ...]
Sent: Wednesday, November 21, 2012 10:02
To: Sylvain Joyeux
Cc: orocos-users [..] ...
Subject: Re: [Orocos-users] proposal to solve inconsistency in KDL types (only the geometric primitives)
On 11/21/2012 09:52 AM, Sylvain Joyeux wrote:
> On 11/21/2012 07:27 AM, Herman Bruyninckx wrote:
>>
>> Any feedback is welcome.
>> I am all for adding correct semantics to the whole process of robot
>> software development, but _not_ in C++ code. My position is that:
>> - semantics must be added to _models_ (in DSLs, not in C++)
>> - the code should be optimized for execution performance, not for
>> semantic
>> correctness
>> - code should be _generated_, not written.
>> Of course, these goals are not reached in one day, but the suggested
>> changes are a step in the wrong direction, in my opinion.
>>
>> I think KDL should become the most efficient solver library out
>> there, and
>> not just to run on with an operation system or a software framework as
>> basis, but also on "bare metal" such as FPGAs. This implies moving
>> "back"
>> to C, instead of to more C++. (But always in the context of having
>> semantic
>> model on top of the code, of course.)
> I don't agree. (Surprised ?)
>
> First KDL is C++ and the changes that Tinne proposes are non-intrusive
proposal to solve inconsistency in KDL types (only the geometric
Hey Tinne,
On Tue, Nov 20, 2012 at 4:15 PM, Tinne De Laet
<tinne [dot] delaet [..] ...> wrote:
> Hey KDL-users,
>
> The KDL types ("Geometric primitives and their transformations:
> KDL::Vector, KDL::Rotation, KDL::Frame, KDL::Twist, KDL::Wrench) are
> somewhat inconsistent. Some represent data types while others are real
> coordinate representations.
>
> Example:
> 1) KDL::Vector is a "A concrete implementation of a 3 dimensional vector
> class". It can represent a position vector, a linear velocity vector, an
> angular velocity vector, a force vector, a torque vector, ...
> 2) KDL::Rotation, KDL::Frame, KDL::Twist and KDL::Wrench represent a 3x3
> rotation matrix, a 4x4 homogeneous transformation matrix, a 6x1 twist
> vector, and a 6x1 wrench vector, respetively.
>
> As a proposal I would suggest to introduce extra types (which can
> inherit from KDL::Vector)
> * KDL::PositionVector
> * KDL::LinearVelocityVector
> * KDL::AngularVelocityVector
> * KDL::ForceVector
> * KDL::TorqueVector
>
So if I get this correctly we are only talking about KDL::Vector?
Would this mean that KDL::Vector would disappear in the long end?
>
> This is the basic idea of the proposed change. I believe it will not be
> very intrusive.
> Nevertheless, if we push this idea to its limits it will probably cause
> an API break
> For instance: The constructor Frame (const Rotation &R, const Vector &V)
> will be replaced by Frame (const Rotation &R, const PositionVector &V)
>
I'm not against adding these classes, I would not like to break the
Frame constructor API since this function is probably close to the
most used functions of KDL. We could off course add the new
constructor and mark the old one deprecated. This way we give users a
chance to migrate.
>
> Any feedback is welcome.
Any patches are welcome ;)
> Tinne
Ruben
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
proposal to solve inconsistency in KDL types (only the geometric
On 11/20/2012 04:47 PM, Ruben Smits wrote:
> Hey Tinne,
>
> On Tue, Nov 20, 2012 at 4:15 PM, Tinne De Laet
> <tinne [dot] delaet [..] ...> wrote:
>> Hey KDL-users,
>>
>> The KDL types ("Geometric primitives and their transformations:
>> KDL::Vector, KDL::Rotation, KDL::Frame, KDL::Twist, KDL::Wrench) are
>> somewhat inconsistent. Some represent data types while others are real
>> coordinate representations.
>>
>> Example:
>> 1) KDL::Vector is a "A concrete implementation of a 3 dimensional vector
>> class". It can represent a position vector, a linear velocity vector, an
>> angular velocity vector, a force vector, a torque vector, ...
>> 2) KDL::Rotation, KDL::Frame, KDL::Twist and KDL::Wrench represent a 3x3
>> rotation matrix, a 4x4 homogeneous transformation matrix, a 6x1 twist
>> vector, and a 6x1 wrench vector, respetively.
>>
>> As a proposal I would suggest to introduce extra types (which can
>> inherit from KDL::Vector)
>> * KDL::PositionVector
>> * KDL::LinearVelocityVector
>> * KDL::AngularVelocityVector
>> * KDL::ForceVector
>> * KDL::TorqueVector
>>
> So if I get this correctly we are only talking about KDL::Vector?
> Would this mean that KDL::Vector would disappear in the long end?
I was not planning to remove it. I think it can still contain all the
functionality that is relevant for a general 3x1 vector (like getting
the x-coordinates, ...)
But operations that are only meaningful for a particular geometric
relation will be specific for the new classes. For instance: integrating
a LinearVelocityVector will result in a PositionVector, while
integrating a PositionVector will not be available (or have at least
another meaning).
>> This is the basic idea of the proposed change. I believe it will not be
>> very intrusive.
>> Nevertheless, if we push this idea to its limits it will probably cause
>> an API break
>> For instance: The constructor Frame (const Rotation &R, const Vector &V)
>> will be replaced by Frame (const Rotation &R, const PositionVector &V)
>>
> I'm not against adding these classes, I would not like to break the
> Frame constructor API since this function is probably close to the
> most used functions of KDL. We could off course add the new
> constructor and mark the old one deprecated. This way we give users a
> chance to migrate.
>
>> Any feedback is welcome.
> Any patches are welcome ;)
Of course. I was just exploring if my patches would have a chance to get
accepted.
Tinne
proposal to solve inconsistency in KDL types (only the geometric
On 11/20/2012 05:32 PM, Tinne De Laet wrote:
> On 11/20/2012 04:47 PM, Ruben Smits wrote:
>> Hey Tinne,
>>
>> On Tue, Nov 20, 2012 at 4:15 PM, Tinne De Laet
>> <tinne [dot] delaet [..] ...> wrote:
>>> Hey KDL-users,
>>>
>>> The KDL types ("Geometric primitives and their transformations:
>>> KDL::Vector, KDL::Rotation, KDL::Frame, KDL::Twist, KDL::Wrench) are
>>> somewhat inconsistent. Some represent data types while others are real
>>> coordinate representations.
>>>
>>> Example:
>>> 1) KDL::Vector is a "A concrete implementation of a 3 dimensional vector
>>> class". It can represent a position vector, a linear velocity vector, an
>>> angular velocity vector, a force vector, a torque vector, ...
>>> 2) KDL::Rotation, KDL::Frame, KDL::Twist and KDL::Wrench represent a 3x3
>>> rotation matrix, a 4x4 homogeneous transformation matrix, a 6x1 twist
>>> vector, and a 6x1 wrench vector, respetively.
In my view, there is indeed a small inconsistency. But it need not to
be resolved in
the proposed way. KDL::Vector just represents a computational object:
it represents a vector
with 3 elements. No other semantics is attached to it. KDL::Rotation
represents a 3x3 matrix representation
of a orthonormal matrix with determinant == 1. No more, no less.
KDL::Frame represents a homogenuous
matrix. No more, no less.
The inconsistency is that KDL::Twist and KDL::Wrench attach a little
more semantics, so to be more consistent
we could replace them with a unifying datatype to be used for both
KDL::Twist/KDL::Wrench.
( This would also lead to a less pervasive change in the API from a user
perspective, then what you propose).
The above proposition corresponds with what we already do when we
describe kinematic algorithms: You typically
only specify semantics if they matter for the algorithm at hand. If
they do not matter, you leave them out, it
makes your algorithm more universal. KDL and KDL operations are much
more universal when you do not
attach the PositionVector, LinearVelocityVector, etc... semantics.
The error that you make is that you attach to much semantics to the KDL
types.
(probably, this bias towards attaching semantics is introduced because
of your interesting work
regarding geometric semantics
http://www.orocos.org/wiki/geometric-relations-semantics-wiki)
If you attach to much semantics to the KDL types, it will lead you to a
combinatorial explosion
of objects and operations, such as:
- what with velocities, accelerations, jerks ?
- what with normal vectors , rotational velocities, rotational
accelerations, rotational jerks, ....
- what with derivatives (and higher order derivatives) to other
variables, possibly combined with time, etc...
- what with time derivative of a force ?
- ....
( all of the above examples are not fictional, but already occurred in
KDL code).
Do not forget, you also have to define interactions between all these
types of new objects ! The above
proposal is only useful if you implement a completely closed
computational domain with your objects.
(i.e. with _all_ possibly relevant operations defined).
That you can fall back to KDL::Vector is a weak argument, because, in
practice, because of the above
combinatorial explosion, there will be many cases were you always will
be forced to fall back. If you do not
implement the whole computational domain, you will have replaced a small
inconsistency with a much larger
inconsistency.
The solution is described above. Just regard the KDL types as
computational objects, with no further semantics
attached (including position/velocity/etc. semantics)
You can attach semantics (this and other types of semantics) later on,
when you are describing e.g. component interfaces.
Best regards,
Erwin.
>>> As a proposal I would suggest to introduce extra types (which can
>>> inherit from KDL::Vector)
>>> * KDL::PositionVector
>>> * KDL::LinearVelocityVector
>>> * KDL::AngularVelocityVector
>>> * KDL::ForceVector
>>> * KDL::TorqueVector
>>>
>> So if I get this correctly we are only talking about KDL::Vector?
>> Would this mean that KDL::Vector would disappear in the long end?
> I was not planning to remove it. I think it can still contain all the
> functionality that is relevant for a general 3x1 vector (like getting
> the x-coordinates, ...)
> But operations that are only meaningful for a particular geometric
> relation will be specific for the new classes. For instance: integrating
> a LinearVelocityVector will result in a PositionVector, while
> integrating a PositionVector will not be available (or have at least
> another meaning).
>>> This is the basic idea of the proposed change. I believe it will not be
>>> very intrusive.
>>> Nevertheless, if we push this idea to its limits it will probably cause
>>> an API break
>>> For instance: The constructor Frame (const Rotation &R, const Vector &V)
>>> will be replaced by Frame (const Rotation &R, const PositionVector &V)
>>>
>> I'm not against adding these classes, I would not like to break the
>> Frame constructor API since this function is probably close to the
>> most used functions of KDL. We could off course add the new
>> constructor and mark the old one deprecated. This way we give users a
>> chance to migrate.
>>
>>> Any feedback is welcome.
>> Any patches are welcome ;)
> Of course. I was just exploring if my patches would have a chance to get
> accepted.
>
> Tinne
proposal to solve inconsistency in KDL types (only the geometric
On 11/20/2012 07:29 PM, Erwin Aertbelien wrote:
>
> On 11/20/2012 05:32 PM, Tinne De Laet wrote:
>> On 11/20/2012 04:47 PM, Ruben Smits wrote:
>>> Hey Tinne,
>>>
>>> On Tue, Nov 20, 2012 at 4:15 PM, Tinne De Laet
>>> <tinne [dot] delaet [..] ...> wrote:
>>>> Hey KDL-users,
>>>>
>>>> The KDL types ("Geometric primitives and their transformations:
>>>> KDL::Vector, KDL::Rotation, KDL::Frame, KDL::Twist, KDL::Wrench) are
>>>> somewhat inconsistent. Some represent data types while others are real
>>>> coordinate representations.
>>>> Example:
>>>> 1) KDL::Vector is a "A concrete implementation of a 3 dimensional vector
>>>> class". It can represent a position vector, a linear velocity vector, an
>>>> angular velocity vector, a force vector, a torque vector, ...
>>>> 2) KDL::Rotation, KDL::Frame, KDL::Twist and KDL::Wrench represent a 3x3
>>>> rotation matrix, a 4x4 homogeneous transformation matrix, a 6x1 twist
>>>> vector, and a 6x1 wrench vector, respetively.
> In my view, there is indeed a small inconsistency. But it need not to
> be resolved in
> the proposed way. KDL::Vector just represents a computational object:
> it represents a vector
> with 3 elements. No other semantics is attached to it. KDL::Rotation
> represents a 3x3 matrix representation
> of a orthonormal matrix with determinant == 1. No more, no less.
> KDL::Frame represents a homogenuous
> matrix. No more, no less.
I do not agree.
* First of all there is the name KDL::Rotation. If its a mere 3x3
orthonormal matrix, why is not called KDL::OrthonormalMatrixThreeByThree.
* Secondly, look for instance at all the operations provided in
KDL::Rotation.
void DoRotX
<http://people.mech.kuleuven.be/%7Ersmits/kdl/api/html/classKDL_1_1Rotation.html#a3d4d9eb4bb5af7bc2aa75d20d64d4c52>
(double angle)
The DoRot.
void DoRotY
<http://people.mech.kuleuven.be/%7Ersmits/kdl/api/html/classKDL_1_1Rotation.html#ab46b48d9ceedf422f62c4398d6aa7af9>
(double angle)
The DoRot.
void DoRotZ
<http://people.mech.kuleuven.be/%7Ersmits/kdl/api/html/classKDL_1_1Rotation.html#a1f614b6e267532e1b92732c9a2a0bfdd>
(double angle)
The DoRot.
Vector
<http://people.mech.kuleuven.be/%7Ersmits/kdl/api/html/classKDL_1_1Vector.html>
GetRot
<http://people.mech.kuleuven.be/%7Ersmits/kdl/api/html/classKDL_1_1Rotation.html#aa3ce2fd7bcd7063497febc76110cc5b2>
() const
Returns a vector with the direction of the equiv.
double GetRotAngle
<http://people.mech.kuleuven.be/%7Ersmits/kdl/api/html/classKDL_1_1Rotation.html#a4d52c3e6597db828256a3ebcc7c3304c>
(Vector
<http://people.mech.kuleuven.be/%7Ersmits/kdl/api/html/classKDL_1_1Vector.html>
&axis, double eps=epsilon) const
Returns the rotation angle around the equiv.
void GetEulerZYZ
<http://people.mech.kuleuven.be/%7Ersmits/kdl/api/html/classKDL_1_1Rotation.html#a33c9dc7a5044ade6542d9a2f61e1a180>
(double &alfa, double &beta, double &gamma) const
Gives back the EulerZYZ convention description of the rotation matrix :
First rotate around Z with alfa, then around the new Y with beta, then
around new Z with gamma.
void GetQuaternion
<http://people.mech.kuleuven.be/%7Ersmits/kdl/api/html/classKDL_1_1Rotation.html#a37f92d1b2c5e9708771543c521c276c4>
(double &x, double &y, double &z, double &w) const
Get the quaternion of this matrix.
void GetRPY
<http://people.mech.kuleuven.be/%7Ersmits/kdl/api/html/classKDL_1_1Rotation.html#a5237f8b3866101f410dce3876be7e5cf>
(double &roll, double &pitch, double &yaw) const
Gives back a vector in RPY coordinates, variables are bound by -PI <=
roll <= PI -PI <= Yaw <= PI -PI/2 <= PITCH <= PI/2.
void GetEulerZYX
<http://people.mech.kuleuven.be/%7Ersmits/kdl/api/html/classKDL_1_1Rotation.html#ae927b1f8077d6e827ea2968ca20af136>
(double &Alfa, double &Beta, double &Gamma) const
GetEulerZYX gets the euler ZYX parameters of a rotation : First rotate
around Z with alfa, then around the new Y with beta, then around new X
with gamma.
These are all operations that explicitly attach the meaning of a
rotation matrix to KDL::Rotation.
> The inconsistency is that KDL::Twist and KDL::Wrench attach a little
> more semantics, so to be more consistent
> we could replace them with a unifying datatype to be used for both
> KDL::Twist/KDL::Wrench.
> ( This would also lead to a less pervasive change in the API from a
> user perspective, then what you propose).
It would indeed make sense to make a class KDL::VectorSixByOne that can
group that functionality that they have in common.
>
> The above proposition corresponds with what we already do when we
> describe kinematic algorithms: You typically
> only specify semantics if they matter for the algorithm at hand. If
> they do not matter, you leave them out, it
> makes your algorithm more universal. KDL and KDL operations are much
> more universal when you do not
> attach the PositionVector, LinearVelocityVector, etc... semantics.
>
>
>
> The error that you make is that you attach to much semantics to the
> KDL types.
> (probably, this bias towards attaching semantics is introduced
> because of your interesting work
> regarding geometric semantics
> http://www.orocos.org/wiki/geometric-relations-semantics-wiki)
>
> If you attach to much semantics to the KDL types, it will lead you to
> a combinatorial explosion
> of objects and operations, such as:
> - what with velocities, accelerations, jerks ?
> - what with normal vectors , rotational velocities, rotational
> accelerations, rotational jerks, ....
> - what with derivatives (and higher order derivatives) to other
> variables, possibly combined with time, etc...
> - what with time derivative of a force ?
> - ....
> ( all of the above examples are not fictional, but already occurred in
> KDL code).
> Do not forget, you also have to define interactions between all these
> types of new objects ! The above
> proposal is only useful if you implement a completely closed
> computational domain with your objects.
> (i.e. with _all_ possibly relevant operations defined).
>
> That you can fall back to KDL::Vector is a weak argument, because, in
> practice, because of the above
> combinatorial explosion, there will be many cases were you always will
> be forced to fall back. If you do not
> implement the whole computational domain, you will have replaced a
> small inconsistency with a much larger
> inconsistency.
>
> The solution is described above. Just regard the KDL types as
> computational objects, with no further semantics
> attached (including position/velocity/etc. semantics)
Then all operations that attach semantic meaning have to removed as
well!!! And then you end up with a matrix library (such as eigen)
Tinne
>
>
> You can attach semantics (this and other types of semantics) later on,
> when you are describing e.g. component interfaces.
>
>
> Best regards,
>
> Erwin.
>
>
>>>> As a proposal I would suggest to introduce extra types (which can
>>>> inherit from KDL::Vector)
>>>> * KDL::PositionVector
>>>> * KDL::LinearVelocityVector
>>>> * KDL::AngularVelocityVector
>>>> * KDL::ForceVector
>>>> * KDL::TorqueVector
>>>>
>>> So if I get this correctly we are only talking about KDL::Vector?
>>> Would this mean that KDL::Vector would disappear in the long end?
>> I was not planning to remove it. I think it can still contain all the
>> functionality that is relevant for a general 3x1 vector (like getting
>> the x-coordinates, ...)
>> But operations that are only meaningful for a particular geometric
>> relation will be specific for the new classes. For instance: integrating
>> a LinearVelocityVector will result in a PositionVector, while
>> integrating a PositionVector will not be available (or have at least
>> another meaning).
>>>> This is the basic idea of the proposed change. I believe it will not be
>>>> very intrusive.
>>>> Nevertheless, if we push this idea to its limits it will probably cause
>>>> an API break
>>>> For instance: The constructor Frame (const Rotation &R, const Vector &V)
>>>> will be replaced by Frame (const Rotation &R, const PositionVector &V)
>>>>
>>> I'm not against adding these classes, I would not like to break the
>>> Frame constructor API since this function is probably close to the
>>> most used functions of KDL. We could off course add the new
>>> constructor and mark the old one deprecated. This way we give users a
>>> chance to migrate.
>>>
>>>> Any feedback is welcome.
>>> Any patches are welcome ;)
>> Of course. I was just exploring if my patches would have a chance to get
>> accepted.
>>
>> Tinne
>
>
>
proposal to solve inconsistency in KDL types (only the geometric
I like the idea of adding some more semantics to KDL types, but I'd be
interested in exploring a more general way of doing this. For example,
with your proposed implementation, interesting things would arise when
performing vector algebra. For example, taking the cross product of a
PositionVector and a ForceVector might result in a TorqueVector, but
what happens when you cross a TorqueVector with an
AngularVelocityVector?
Maybe instead of using polymorphism we can just add generalized units
that get propagated with operations? And if so, are there any other
libraries that do this?
I'd say the best thing to do is create your own fork of KDL on github
and add your changes to try them out.
Also, as an aside, any API break could be mitigated by adding
deprecation warnings for the old functions.
On Tue, Nov 20, 2012 at 10:15 AM, Tinne De Laet
<tinne [dot] delaet [..] ...> wrote:
> Hey KDL-users,
>
> The KDL types ("Geometric primitives and their transformations:
> KDL::Vector, KDL::Rotation, KDL::Frame, KDL::Twist, KDL::Wrench) are
> somewhat inconsistent. Some represent data types while others are real
> coordinate representations.
>
> Example:
> 1) KDL::Vector is a "A concrete implementation of a 3 dimensional vector
> class". It can represent a position vector, a linear velocity vector, an
> angular velocity vector, a force vector, a torque vector, ...
> 2) KDL::Rotation, KDL::Frame, KDL::Twist and KDL::Wrench represent a 3x3
> rotation matrix, a 4x4 homogeneous transformation matrix, a 6x1 twist
> vector, and a 6x1 wrench vector, respetively.
>
> As a proposal I would suggest to introduce extra types (which can
> inherit from KDL::Vector)
> * KDL::PositionVector
> * KDL::LinearVelocityVector
> * KDL::AngularVelocityVector
> * KDL::ForceVector
> * KDL::TorqueVector
>
>
> This is the basic idea of the proposed change. I believe it will not be
> very intrusive.
> Nevertheless, if we push this idea to its limits it will probably cause
> an API break
> For instance: The constructor Frame (const Rotation &R, const Vector &V)
> will be replaced by Frame (const Rotation &R, const PositionVector &V)
>
>
> Any feedback is welcome.
>
> Tinne
>
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
--
Jonathan Bohren
PhD Student
Dynamical Systems and Control Laboratory
Laboratory for Computational Sensing and Robotics
The Johns Hopkins University
(707) 520-4736
jbo [..] ...
proposal to solve inconsistency in KDL types (only the geometric
On 11/20/2012 04:40 PM, Jonathan Bohren wrote:
> I like the idea of adding some more semantics to KDL types, but I'd be
> interested in exploring a more general way of doing this. For example,
> with your proposed implementation, interesting things would arise when
> performing vector algebra. For example, taking the cross product of a
> PositionVector and a ForceVector might result in a TorqueVector, but
> what happens when you cross a TorqueVector with an
> AngularVelocityVector?
We have been working hard on this but only so far for geometric
relations between rigid bodies (position, orientation, pose, linear
velocity, angular velocity, twist, force, torque, wrench). Result can be
found at: http://www.orocos.org/wiki/geometric-relations-semantics-wiki.
Our idea is not to put all the semantics inside KDL but to use a
geometric semantics library on top of KDL. However our study revealed
some inconsistencies and possibilities for improvement in KDL.
So my goal is just to use our gained knowledge to make KDL more
consistent. Not to make add all the semantics in KDL.
>
> Maybe instead of using polymorphism we can just add generalized units
> that get propagated with operations? And if so, are there any other
> libraries that do this?
I think units is not the way to go. Again, I think that our geometric
relations semantics library is already a small part.
KDL however is doing a lot more than mere geometry. Therefore we have
still to investigate the semantics of kinematics, power, ...
>
> I'd say the best thing to do is create your own fork of KDL on github
> and add your changes to try them out.
Good. I just wanted to check on some objections before going ahead. Just
to prevent that I waste my time on something that will never be accepted
by the community.
>
> Also, as an aside, any API break could be mitigated by adding
> deprecation warnings for the old functions.
Agreed.
Thanks for your feedback,
Tinne
>
> On Tue, Nov 20, 2012 at 10:15 AM, Tinne De Laet
> <tinne [dot] delaet [..] ...> wrote:
>> Hey KDL-users,
>>
>> The KDL types ("Geometric primitives and their transformations:
>> KDL::Vector, KDL::Rotation, KDL::Frame, KDL::Twist, KDL::Wrench) are
>> somewhat inconsistent. Some represent data types while others are real
>> coordinate representations.
>>
>> Example:
>> 1) KDL::Vector is a "A concrete implementation of a 3 dimensional vector
>> class". It can represent a position vector, a linear velocity vector, an
>> angular velocity vector, a force vector, a torque vector, ...
>> 2) KDL::Rotation, KDL::Frame, KDL::Twist and KDL::Wrench represent a 3x3
>> rotation matrix, a 4x4 homogeneous transformation matrix, a 6x1 twist
>> vector, and a 6x1 wrench vector, respetively.
>>
>> As a proposal I would suggest to introduce extra types (which can
>> inherit from KDL::Vector)
>> * KDL::PositionVector
>> * KDL::LinearVelocityVector
>> * KDL::AngularVelocityVector
>> * KDL::ForceVector
>> * KDL::TorqueVector
>>
>>
>> This is the basic idea of the proposed change. I believe it will not be
>> very intrusive.
>> Nevertheless, if we push this idea to its limits it will probably cause
>> an API break
>> For instance: The constructor Frame (const Rotation &R, const Vector &V)
>> will be replaced by Frame (const Rotation &R, const PositionVector &V)
>>
>>
>> Any feedback is welcome.
>>
>> Tinne
>>
>>
>> --
>> Orocos-Users mailing list
>> Orocos-Users [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>
> --
> Jonathan Bohren
> PhD Student
> Dynamical Systems and Control Laboratory
> Laboratory for Computational Sensing and Robotics
> The Johns Hopkins University
>
> (707) 520-4736
> jbo [..] ...
proposal to solve inconsistency in KDL types (only the geometric
On Tue, Nov 20, 2012 at 11:27 AM, Tinne De Laet
<tinne [dot] delaet [..] ...> wrote:
> On 11/20/2012 04:40 PM, Jonathan Bohren wrote:
>>
>> I like the idea of adding some more semantics to KDL types, but I'd be
>> interested in exploring a more general way of doing this. For example,
>> with your proposed implementation, interesting things would arise when
>> performing vector algebra. For example, taking the cross product of a
>> PositionVector and a ForceVector might result in a TorqueVector, but
>> what happens when you cross a TorqueVector with an
>> AngularVelocityVector?
>
>
> We have been working hard on this but only so far for geometric relations
> between rigid bodies (position, orientation, pose, linear velocity, angular
> velocity, twist, force, torque, wrench). Result can be found at:
> http://www.orocos.org/wiki/geometric-relations-semantics-wiki.
> Our idea is not to put all the semantics inside KDL but to use a geometric
> semantics library on top of KDL. However our study revealed some
> inconsistencies and possibilities for improvement in KDL.
> So my goal is just to use our gained knowledge to make KDL more consistent.
> Not to make add all the semantics in KDL.
Ah right! I had forgotten about this. I remember finding it a bit
verbose syntactically, were there any alternative syntaxes that you
experimented with?
Personally, I find the API calls like "Pose<KDL::Frame>
pose1("a","e","C","b","f","D","f",coordinatesPose)" really hard to
read.
-j
proposal to solve inconsistency in KDL types (only the geometric
On 11/20/2012 04:15 PM, Tinne De Laet wrote:
> Hey KDL-users,
>
> The KDL types ("Geometric primitives and their transformations:
> KDL::Vector, KDL::Rotation, KDL::Frame, KDL::Twist, KDL::Wrench) are
> somewhat inconsistent. Some represent data types while others are real
> coordinate representations.
>
> Example:
> 1) KDL::Vector is a "A concrete implementation of a 3 dimensional vector
> class". It can represent a position vector, a linear velocity vector, an
> angular velocity vector, a force vector, a torque vector, ...
> 2) KDL::Rotation, KDL::Frame, KDL::Twist and KDL::Wrench represent a 3x3
> rotation matrix, a 4x4 homogeneous transformation matrix, a 6x1 twist
> vector, and a 6x1 wrench vector, respetively.
>
> As a proposal I would suggest to introduce extra types (which can
> inherit from KDL::Vector)
> * KDL::PositionVector
> * KDL::LinearVelocityVector
> * KDL::AngularVelocityVector
> * KDL::ForceVector
> * KDL::TorqueVector
>
>
If the road is to give more semantic meaning, also joint effort should
be differentiated by joint position/velocity vectors....
> This is the basic idea of the proposed change. I believe it will not be
> very intrusive.
> Nevertheless, if we push this idea to its limits it will probably cause
> an API break
> For instance: The constructor Frame (const Rotation &R, const Vector &V)
> will be replaced by Frame (const Rotation &R, const PositionVector &V)
>
>
> Any feedback is welcome.
>
> Tinne
>
>
proposal to solve inconsistency in KDL types (only the geometric
On 11/20/2012 04:24 PM, Gianni Borghesan wrote:
>
>
> On 11/20/2012 04:15 PM, Tinne De Laet wrote:
>> Hey KDL-users,
>>
>> The KDL types ("Geometric primitives and their transformations:
>> KDL::Vector, KDL::Rotation, KDL::Frame, KDL::Twist, KDL::Wrench) are
>> somewhat inconsistent. Some represent data types while others are real
>> coordinate representations.
>>
>> Example:
>> 1) KDL::Vector is a "A concrete implementation of a 3 dimensional vector
>> class". It can represent a position vector, a linear velocity vector, an
>> angular velocity vector, a force vector, a torque vector, ...
>> 2) KDL::Rotation, KDL::Frame, KDL::Twist and KDL::Wrench represent a 3x3
>> rotation matrix, a 4x4 homogeneous transformation matrix, a 6x1 twist
>> vector, and a 6x1 wrench vector, respetively.
>>
>> As a proposal I would suggest to introduce extra types (which can
>> inherit from KDL::Vector)
>> * KDL::PositionVector
>> * KDL::LinearVelocityVector
>> * KDL::AngularVelocityVector
>> * KDL::ForceVector
>> * KDL::TorqueVector
>>
>>
>
> If the road is to give more semantic meaning, also joint effort should
you mean jntArray?
> be differentiated by joint position/velocity vectors....
>
>
>> This is the basic idea of the proposed change. I believe it will not be
>> very intrusive.
>> Nevertheless, if we push this idea to its limits it will probably cause
>> an API break
>> For instance: The constructor Frame (const Rotation &R, const Vector &V)
>> will be replaced by Frame (const Rotation &R, const PositionVector &V)
>>
>>
>> Any feedback is welcome.
>>
>> Tinne
>>
>>
>