KDL and dynamics of branched models

Hello everyone,

I am the author of the RBDL - the rigid body dynamics library, that is
being developed at https://bitbucket.org/rbdl/rbdl. I just found out
about KDL and try to find similarities and differences of RBDL and KDL.

I was wondering whethering whether KDL supports forward and/or inverse
dynamics of branched models. From the web page and documentation it
seems to me as if KDL only supports serial chain structures, yet in the
wiki it speaks of biomechanical human models, which I would have assumed
to be a branched model instead of a chain.

Are there any benchmarks available?

Best regards,
Martin

KDL and dynamics of branched models

On Thu, 19 Jul 2012, Martin Felis wrote:

> Hello everyone,
>
> I am the author of the RBDL - the rigid body dynamics library, that is
> being developed at https://bitbucket.org/rbdl/rbdl.

Why is it that people keep on reinventing wheels...? :-)
- <http://sourceforge.net/projects/stanford-wbc/>
- the similar dynamics in OpenSim, simbody
<https://simtk.org/home/simbody>
- ...

> I just found out about KDL and try to find similarities and differences
> of RBDL and KDL.
>
> I was wondering whethering whether KDL supports forward and/or inverse
> dynamics of branched models. From the web page and documentation it
> seems to me as if KDL only supports serial chain structures, yet in the
> wiki it speaks of biomechanical human models, which I would have assumed
> to be a branched model instead of a chain.

We have trees indeed. And there is currently a _thorough_ improvement
ongoing in this direction, with more functionality and higher flexibility
in composition of "solvers".

> Are there any benchmarks available?

What kind of benchmark do you have in mind?

I invite you to collaborate, instead of trying to differentiate on small
things.

> Best regards,
> Martin

Best regards,

Herman Bruyninckx

>

KDL and dynamics of branched models

On 20/07/12 09:38, Herman Bruyninckx wrote:
> On Thu, 19 Jul 2012, Martin Felis wrote:
> Why is it that people keep on reinventing wheels...? :-)
> - <http://sourceforge.net/projects/stanford-wbc/>
> - the similar dynamics in OpenSim, simbody
> <https://simtk.org/home/simbody>
> - ...

I guess sometimes the journey is the reward and not necessarily the
wheel ;D.

I do trajectory optimizations of robot motions with branched models with
contact constraints in the range of 15-35+ degrees of freedom for which
I need to compute the dynamics *very* often and therefore need a fast
code for the forward dynamics.

At the time when I started RBDL (sometime in 2010) I was looking for a
replacement for an existing but rather inflexible forward dynamics code
that can handle contact constraints. The packages that I found had
either incompatible licenses (not for me personally but for the code I
work with) and often seemed to be big simulation packages which came
with a lot of other dependencies.

> What kind of benchmark do you have in mind?

A benchmark for the forward dynamics, i.e. how much time does the
forward dynamics computation of a model with X degrees of freedom take.

> I invite you to collaborate, instead of trying to differentiate on small
> things.

Thank you very much for the invitation. I will keep that in mind.

Martin

KDL and dynamics of branched models

On Fri, 20 Jul 2012, Martin Felis wrote:

> On 20/07/12 09:38, Herman Bruyninckx wrote:
>> On Thu, 19 Jul 2012, Martin Felis wrote:
>> Why is it that people keep on reinventing wheels...? :-)
>> - <http://sourceforge.net/projects/stanford-wbc/>
>> - the similar dynamics in OpenSim, simbody
>> <https://simtk.org/home/simbody>
>> - ...
>
> I guess sometimes the journey is the reward and not necessarily the wheel ;D.
>
> I do trajectory optimizations of robot motions with branched models with
> contact constraints in the range of 15-35+ degrees of freedom for which I
> need to compute the dynamics *very* often and therefore need a fast code for
> the forward dynamics.
>
> At the time when I started RBDL (sometime in 2010) I was looking for a
> replacement for an existing but rather inflexible forward dynamics code that
> can handle contact constraints. The packages that I found had either
> incompatible licenses (not for me personally but for the code I work with)
> and often seemed to be big simulation packages which came with a lot of other
> dependencies.

But KDL would have been the perfect base to start from, both content-wise
and license-wise :-) Or wasn't it?

>> What kind of benchmark do you have in mind?
>
> A benchmark for the forward dynamics, i.e. how much time does the forward
> dynamics computation of a model with X degrees of freedom take.

>> I invite you to collaborate, instead of trying to differentiate on small
>> things.
>
> Thank you very much for the invitation. I will keep that in mind.
>
> Martin

Herman

KDL and dynamics of branched models

On 20/07/12 15:57, Herman Bruyninckx wrote:
> On Fri, 20 Jul 2012, Martin Felis wrote:
>
>> On 20/07/12 09:38, Herman Bruyninckx wrote:
>>> On Thu, 19 Jul 2012, Martin Felis wrote:
>>> Why is it that people keep on reinventing wheels...? :-)
>>
>> I guess sometimes the journey is the reward and not necessarily the
>> wheel ;D.
>>
>> I do trajectory optimizations of robot motions with branched models
>> with contact constraints in the range of 15-35+ degrees of freedom for
>> which I need to compute the dynamics *very* often and therefore need a
>> fast code for the forward dynamics.
>
> But KDL would have been the perfect base to start from, both content-wise
> and license-wise :-) Or wasn't it?

It could have been.

Regards,
Martin

KDL and dynamics of branched models

Hi,

since it is relevant for my next project, I will be happy to make a benchmark of RBDL vs KDL and to define the difference in terms of functionalities.

Something that I found very interesting in RBDL is the possibility to define custom joints with any number of degree of freedom.

I would love to see these two project collaborating to create together something a new kinematic and dynamic library. Very often I heard on this mailing list that KDL need some refactoring, but it was never clear to me how far in the future this is.

Davide

KDL and dynamics of

On Wed, 25 Jul 2012, faconti [..] ... wrote:

> Hi,
>
> since it is relevant for my next project, I will be happy to make a benchmark
> of RBDL vs KDL and to define the difference in terms of functionalities.
>
> Something that I found very interesting in RBDL is the possibility to define
> custom joints with any number of degree of freedom.

This is a "Good Thing"!

> I would love to see these two project collaborating to create together
> something a new kinematic and dynamic library.

I agree!

> Very often I heard on this mailing list that KDL need some refactoring, but
> it was never clear to me how far in the future this is.

We now have a Summer intern doing some refactoring, but that is not (yet)
dealing with new/improved _features_. (Erwin is supervising this work.)

A PhD student, Azamat Shakhimardanov, is now working on the infrastructure
to provide efficient "iterators" over the kinematic trees for calling the
variety of "function blocks" that are needed when composing a complex
dynammics algorithm; "complex" means: not just doing Newton-Euler
recursion (this can be done with a "map"/"linked pointers" (KDL) or
"vector" (RBDL), but the latter solutions have problems when iterating with
_non-homogeneous_ function types at each traversal of joint and segment.
"Non-homogeneous" = joint limit avoidance control, linear time acceleration
constraint propagation, MPC control, etc.
(I am supervising this work.)

If there is interest in having a common workshop on how to go further
together, I am very willing to organize that.

> Davide

Herman

KDL and dynamics of

On Thu, Jul 26, 2012 at 9:31 AM, Herman Bruyninckx <
Herman [dot] Bruyninckx [..] ...> wrote:

> On Wed, 25 Jul 2012, faconti [..] ... wrote:
>
> > Hi,
> >
> > since it is relevant for my next project, I will be happy to make a
> benchmark
> > of RBDL vs KDL and to define the difference in terms of functionalities.
> >
> > Something that I found very interesting in RBDL is the possibility to
> define
> > custom joints with any number of degree of freedom.
>
> This is a "Good Thing"!
>
> > I would love to see these two project collaborating to create together
> > something a new kinematic and dynamic library.
>
> I agree!
>
> > Very often I heard on this mailing list that KDL need some refactoring,
> but
> > it was never clear to me how far in the future this is.
>
> We now have a Summer intern doing some refactoring, but that is not (yet)
> dealing with new/improved _features_. (Erwin is supervising this work.)
>
> A PhD student, Azamat Shakhimardanov, is now working on the infrastructure
> to provide efficient "iterators" over the kinematic trees for calling the
> variety of "function blocks" that are needed when composing a complex
> dynammics algorithm; "complex" means: not just doing Newton-Euler
> recursion (this can be done with a "map"/"linked pointers" (KDL) or
> "vector" (RBDL), but the latter solutions have problems when iterating with
> _non-homogeneous_ function types at each traversal of joint and segment.
> "Non-homogeneous" = joint limit avoidance control, linear time acceleration
> constraint propagation, MPC control, etc.
> (I am supervising this work.)
>
> If there is interest in having a common workshop on how to go further
> together, I am very willing to organize that.
>

I reiterate my interest in these topics and willingness to participate.

Adolfo.

> > Davide
>
> Herman
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

KDL and dynamics of

Hello,

RBDL comes with a benchmark for the different dynamics algorithms (ABA,
RNEA, CRBA, and also the contact dynamics) so there should not be much
work on that side.

RBDL tries to uses std::vectors wherever possible to have constant
access during dynamics computations. All the state information and
properties of all movable bodies are each stored in a std::vector to
have fast access. To ensure that bodies further up in a tree are updated
before their children is achieved by requiring that for a body with
index i all parent bodies must have an index < i. This is also suggested
by Featherstone in his book Rigid Body Dynamics Algorithms.

KDL seems to use std::map<> for assembling the tree structures, which I
fear is not optimal. Is there a specific reason for this? Otherwise when
using a similar numbering scheme one may be able to reuse the structure
and algorithms already developed for the chains.

Martin

On 07/25/2012 05:29 PM, faconti [..] ... wrote:
> Hi,
>
> since it is relevant for my next project, I will be happy to make a benchmark
> of RBDL vs KDL and to define the difference in terms of functionalities.
>
> Something that I found very interesting in RBDL is the possibility to define
> custom joints with any number of degree of freedom.
>
> I would love to see these two project collaborating to create together
> something a new kinematic and dynamic library.
> Very often I heard on this mailing list that KDL need some refactoring, but
> it was never clear to me how far in the future this is.
>
> Davide
>
>

Ruben Smits's picture

KDL and dynamics of

On Wed, Jul 25, 2012 at 6:23 PM, Martin Felis
<martin [dot] felis [..] ...> wrote:
> Hello,
>
> RBDL comes with a benchmark for the different dynamics algorithms (ABA,
> RNEA, CRBA, and also the contact dynamics) so there should not be much
> work on that side.
>
> RBDL tries to uses std::vectors wherever possible to have constant
> access during dynamics computations. All the state information and
> properties of all movable bodies are each stored in a std::vector to
> have fast access. To ensure that bodies further up in a tree are updated
> before their children is achieved by requiring that for a body with
> index i all parent bodies must have an index < i. This is also suggested
> by Featherstone in his book Rigid Body Dynamics Algorithms.
>
> KDL seems to use std::map<> for assembling the tree structures, which I
> fear is not optimal. Is there a specific reason for this?

The map is only used to find the starting point for the algorithm (for
instance the end-effector for forward kinematics), each child keeps a
pointer to its parent and each parent keeps a pointer to all its
children for rapid traversing of the tree, the map is not used anymore
at that point. All algorithms that traverse the tree can use these
pointers.

Ruben

> Otherwise when
> using a similar numbering scheme one may be able to reuse the structure
> and algorithms already developed for the chains.
>
> Martin
>
> On 07/25/2012 05:29 PM, faconti [..] ... wrote:
>> Hi,
>>
>> since it is relevant for my next project, I will be happy to make a benchmark
>> of RBDL vs KDL and to define the difference in terms of functionalities.
>>
>> Something that I found very interesting in RBDL is the possibility to define
>> custom joints with any number of degree of freedom.
>>
>> I would love to see these two project collaborating to create together
>> something a new kinematic and dynamic library.
>> Very often I heard on this mailing list that KDL need some refactoring, but
>> it was never clear to me how far in the future this is.
>>
>> Davide
>>
>>
>
>
> --
> mail : martin [dot] felis [..] ...
> phone : +49 6221 544983
> office: IWR | INF 368 | Room 509 | 69120 Heidelberg | Germany
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users