https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=666
Summary: Adding dynamics primitives and algorithms
Product: KDL
Version: kdl-trunk
Platform: All
OS/Version: All
Status: NEW
Severity: project
Priority: P3
Component: Primitives
AssignedTo: orocos-dev [..] ...
ReportedBy: ruben [dot] smits [..] ...
CC: orocos-dev [..] ...
Estimated Hours: 0.0
During the previous weeks I have been working on the addition of the first
dynamic algorithm to KDL.
I added two new primitives: RotationalInertia and RigidBodyInertia, including
all the operators to change their reference point/frame.
The first algorithm i implemented is the recursive Newton-Euler algorithm as
explained in "Rigid Body Dynamics Algorithms" by Roy Featherstone.
The implementation is fully tested and I verified the results with the robotics
toolbox for a puma560 robot.
I'll add a patch which contains the full code addition/change.
Ruben
[Bug 666] Adding dynamics primitives and algorithms
https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=666
Ruben Smits <ruben [dot] smits [..] ...> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution| |FIXED
Status|NEW |RESOLVED
--- Comment #2 from Ruben Smits <ruben [dot] smits [..] ...> 2009-07-22 14:34:25 ---
It's all committed now. So I consider this one resolved
[Bug 666] Adding dynamics primitives and algorithms
https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=666
--- Comment #1 from Ruben Smits <ruben [dot] smits [..] ...> 2009-06-09 11:28:01 ---
Created an attachment (id=441)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=441)
adds dynamics primitives and algorithm
If no-one has any objections this patch goes in soon. It adds a dependency to
Eigen2. The idea is to completely switch all dependencies on
boost::numeric::ublas to Eigen2.
Ruben
[Bug 666] Adding dynamics primitives and algorithms
On Jun 9, 2009, at 05:28 , Ruben Smits wrote:
> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=666
>
>
>
>
>
> --- Comment #1 from Ruben Smits <ruben [dot] smits [..] ...>
> 2009-06-09 11:28:01 ---
> Created an attachment (id=441)
> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=441)
> adds dynamics primitives and algorithm
>
> If no-one has any objections this patch goes in soon. It adds a
> dependency to
> Eigen2. The idea is to completely switch all dependencies on
> boost::numeric::ublas to Eigen2.
Is Eigen generally available in most distribution's package managers?
I would hate for this change to make it *harder* to satisfy
dependancies.
[Bug 666] Adding dynamics primitives and algorithms
[pushing back to ML]
On Jun 9, 2009, at 08:58 , Ruben Smits wrote:
> eigen2 is a full header template library (just like
> boost::numeric::ublas), and is more performant than boost.
> ubuntu/debian packages are available.
>
> Ruben
>
> On Tue, Jun 9, 2009 at 1:13 PM, S Roderick<kiwi [dot] net [..] ...> wrote:
>> On Jun 9, 2009, at 05:28 , Ruben Smits wrote:
>>
>>> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=666
>>>
>>>
>>>
>>>
>>>
>>> --- Comment #1 from Ruben Smits <ruben [dot] smits [..] ...>
>>> 2009-06-09 11:28:01 ---
>>> Created an attachment (id=441)
>>> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=441)
>>> adds dynamics primitives and algorithm
>>>
>>> If no-one has any objections this patch goes in soon. It adds a
>>> dependency to
>>> Eigen2. The idea is to completely switch all dependencies on
>>> boost::numeric::ublas to Eigen2.
>>
>> Is Eigen generally available in most distribution's package managers?
>> I would hate for this change to make it *harder* to satisfy
>> dependancies.
>>
It is also available in Macports.
I just wanted to bring it up to make others aware. We're hitting more
resistance from customers, with larger open-source packages containing
significant numbers of dependancies.
[Bug 666] Adding dynamics primitives and algorithms
On Jun 9, 2009, at 09:18 , Stephen Roderick wrote:
> [pushing back to ML]
>
> On Jun 9, 2009, at 08:58 , Ruben Smits wrote:
>
>> eigen2 is a full header template library (just like
>> boost::numeric::ublas), and is more performant than boost.
>> ubuntu/debian packages are available.
>>
>> Ruben
>>
>> On Tue, Jun 9, 2009 at 1:13 PM, S Roderick<kiwi [dot] net [..] ...> wrote:
>>> On Jun 9, 2009, at 05:28 , Ruben Smits wrote:
>>>
>>>> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=666
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --- Comment #1 from Ruben Smits <ruben [dot] smits [..] ...>
>>>> 2009-06-09 11:28:01 ---
>>>> Created an attachment (id=441)
>>>> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=441)
>>>> adds dynamics primitives and algorithm
>>>>
>>>> If no-one has any objections this patch goes in soon. It adds a
>>>> dependency to
>>>> Eigen2. The idea is to completely switch all dependencies on
>>>> boost::numeric::ublas to Eigen2.
>>>
>>> Is Eigen generally available in most distribution's package
>>> managers?
>>> I would hate for this change to make it *harder* to satisfy
>>> dependancies.
>>>
>
> It is also available in Macports.
>
> I just wanted to bring it up to make others aware. We're hitting more
> resistance from customers, with larger open-source packages containing
> significant numbers of dependancies.
Just so people know, eigen2 is not avaliable in Ubuntu until Intrepid.
It also is not available Debian Lenny, and can't be built with the
current version of cmake available in Debian Lenny (2.6.0, it needs at
least 2.6.2). So you'll have to source build CMake first, before
source building Eigen2
Is there no way to continue to support the boost library?
Cheers
Stephen
[Bug 666] Adding dynamics primitives and algorithms
On Mon, Jun 15, 2009 at 6:09 PM, S Roderick<kiwi [dot] net [..] ...> wrote:
> On Jun 9, 2009, at 09:18 , Stephen Roderick wrote:
>
>> [pushing back to ML]
>>
>> On Jun 9, 2009, at 08:58 , Ruben Smits wrote:
>>
>>> eigen2 is a full header template library (just like
>>> boost::numeric::ublas), and is more performant than boost.
>>> ubuntu/debian packages are available.
>>>
>>> Ruben
>>>
>>> On Tue, Jun 9, 2009 at 1:13 PM, S Roderick<kiwi [dot] net [..] ...> wrote:
>>>> On Jun 9, 2009, at 05:28 , Ruben Smits wrote:
>>>>
>>>>> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=666
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --- Comment #1 from Ruben Smits <ruben [dot] smits [..] ...>
>>>>> 2009-06-09 11:28:01 ---
>>>>> Created an attachment (id=441)
>>>>> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=441)
>>>>> adds dynamics primitives and algorithm
>>>>>
>>>>> If no-one has any objections this patch goes in soon. It adds a
>>>>> dependency to
>>>>> Eigen2. The idea is to completely switch all dependencies on
>>>>> boost::numeric::ublas to Eigen2.
>>>>
>>>> Is Eigen generally available in most distribution's package
>>>> managers?
>>>> I would hate for this change to make it *harder* to satisfy
>>>> dependancies.
>>>>
>>
>> It is also available in Macports.
>>
>> I just wanted to bring it up to make others aware. We're hitting more
>> resistance from customers, with larger open-source packages containing
>> significant numbers of dependancies.
>
> Just so people know, eigen2 is not avaliable in Ubuntu until Intrepid.
>
> It also is not available Debian Lenny, and can't be built with the
> current version of cmake available in Debian Lenny (2.6.0, it needs at
> least 2.6.2). So you'll have to source build CMake first, before
> source building Eigen2
You do not need to compile Eigen2, so just getting the sources and
putting it somewhere on your system should be enough.
> Is there no way to continue to support the boost library?
>
I could put the Eigen2 sources in the KDL-tree, if this helps you.
> Cheers
> Stephen
>
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
[Bug 666] Adding dynamics primitives and algorithms
On Jun 16, 2009, at 07:10 , Ruben Smits wrote:
> On Mon, Jun 15, 2009 at 6:09 PM, S Roderick<kiwi [dot] net [..] ...> wrote:
>> On Jun 9, 2009, at 09:18 , Stephen Roderick wrote:
>>
>>> [pushing back to ML]
>>>
>>> On Jun 9, 2009, at 08:58 , Ruben Smits wrote:
>>>
>>>> eigen2 is a full header template library (just like
>>>> boost::numeric::ublas), and is more performant than boost.
>>>> ubuntu/debian packages are available.
>>>>
>>>> Ruben
>>>>
>>>> On Tue, Jun 9, 2009 at 1:13 PM, S Roderick<kiwi [dot] net [..] ...> wrote:
>>>>> On Jun 9, 2009, at 05:28 , Ruben Smits wrote:
>>>>>
>>>>>> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=666
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --- Comment #1 from Ruben Smits <ruben [dot] smits [..] ...>
>>>>>> 2009-06-09 11:28:01 ---
>>>>>> Created an attachment (id=441)
>>>>>> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=441)
>>>>>> adds dynamics primitives and algorithm
>>>>>>
>>>>>> If no-one has any objections this patch goes in soon. It adds a
>>>>>> dependency to
>>>>>> Eigen2. The idea is to completely switch all dependencies on
>>>>>> boost::numeric::ublas to Eigen2.
>>>>>
>>>>> Is Eigen generally available in most distribution's package
>>>>> managers?
>>>>> I would hate for this change to make it *harder* to satisfy
>>>>> dependancies.
>>>>>
>>>
>>> It is also available in Macports.
>>>
>>> I just wanted to bring it up to make others aware. We're hitting
>>> more
>>> resistance from customers, with larger open-source packages
>>> containing
>>> significant numbers of dependancies.
>>
>> Just so people know, eigen2 is not avaliable in Ubuntu until
>> Intrepid.
>>
>> It also is not available Debian Lenny, and can't be built with the
>> current version of cmake available in Debian Lenny (2.6.0, it needs
>> at
>> least 2.6.2). So you'll have to source build CMake first, before
>> source building Eigen2
>
> You do not need to compile Eigen2, so just getting the sources and
> putting it somewhere on your system should be enough.
Good to know! That definitely simplifies the problem.
>> Is there no way to continue to support the boost library?
>>
>
> I could put the Eigen2 sources in the KDL-tree, if this helps you.
I would personally lean away from this, as I'd rather not be tied to a
specific version within a KDL release, and it adds extra maintenance
for the KDL folks. YMMV.
I'm not against the use of Eigen, just trying to reduce the overhead
when using KDL.
Cheers
Stephen
[Bug 666] Adding dynamics primitives and algorithms
On Tue, Jun 16, 2009 at 1:53 PM, Stephen Roderick<kiwi [dot] net [..] ...> wrote:
> On Jun 16, 2009, at 07:10 , Ruben Smits wrote:
>
>> On Mon, Jun 15, 2009 at 6:09 PM, S Roderick<kiwi [dot] net [..] ...> wrote:
>>> On Jun 9, 2009, at 09:18 , Stephen Roderick wrote:
>>>
>>>> [pushing back to ML]
>>>>
>>>> On Jun 9, 2009, at 08:58 , Ruben Smits wrote:
>>>>
>>>>> eigen2 is a full header template library (just like
>>>>> boost::numeric::ublas), and is more performant than boost.
>>>>> ubuntu/debian packages are available.
>>>>>
>>>>> Ruben
>>>>>
>>>>> On Tue, Jun 9, 2009 at 1:13 PM, S Roderick<kiwi [dot] net [..] ...> wrote:
>>>>>> On Jun 9, 2009, at 05:28 , Ruben Smits wrote:
>>>>>>
>>>>>>> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=666
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --- Comment #1 from Ruben Smits <ruben [dot] smits [..] ...>
>>>>>>> 2009-06-09 11:28:01 ---
>>>>>>> Created an attachment (id=441)
>>>>>>> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=441)
>>>>>>> adds dynamics primitives and algorithm
>>>>>>>
>>>>>>> If no-one has any objections this patch goes in soon. It adds a
>>>>>>> dependency to
>>>>>>> Eigen2. The idea is to completely switch all dependencies on
>>>>>>> boost::numeric::ublas to Eigen2.
>>>>>>
>>>>>> Is Eigen generally available in most distribution's package
>>>>>> managers?
>>>>>> I would hate for this change to make it *harder* to satisfy
>>>>>> dependancies.
>>>>>>
>>>>
>>>> It is also available in Macports.
>>>>
>>>> I just wanted to bring it up to make others aware. We're hitting
>>>> more
>>>> resistance from customers, with larger open-source packages
>>>> containing
>>>> significant numbers of dependancies.
>>>
>>> Just so people know, eigen2 is not avaliable in Ubuntu until
>>> Intrepid.
>>>
>>> It also is not available Debian Lenny, and can't be built with the
>>> current version of cmake available in Debian Lenny (2.6.0, it needs
>>> at
>>> least 2.6.2). So you'll have to source build CMake first, before
>>> source building Eigen2
>>
>> You do not need to compile Eigen2, so just getting the sources and
>> putting it somewhere on your system should be enough.
>
> Good to know! That definitely simplifies the problem.
>
>>> Is there no way to continue to support the boost library?
>>>
>>
>> I could put the Eigen2 sources in the KDL-tree, if this helps you.
>
> I would personally lean away from this, as I'd rather not be tied to a
> specific version within a KDL release, and it adds extra maintenance
> for the KDL folks. YMMV.
>
> I'm not against the use of Eigen, just trying to reduce the overhead
> when using KDL.
I second Stephen in this discussion. Some thoughts:
$ fink show-deps eigen2
Information about 9070 packages read in 1 seconds.
Package: eigen2 (2.0.2-1)
To install the compiled package...
The following other packages (and their dependencies) must be installed:
[none]
The following other packages must not be installed:
[none]
To compile this package from source...
The following packages are also compiled at the same time:
[none]
The following other packages (and their dependencies) must be installed:
cmake (>= 2.6.2)
The following other packages must not be installed:
[none]
So there is also a dependency on cmake > 2.6.2. Which seems strange
for a header only package...
About including this in KDL: AFAIK there have been some thoughts
about using eigen2 for BFL too. Which leads me to two additional
thoughts:
- If eigen2 ain't a header only library, including eigen2 into KDL
will lead to double symbols for applications that use both BFL
(wrapping eigen2) and KDL.
- A long time ago, the matrix library was not an integral part of BFL
but a separate library. Since it was only used in BFL, it was
included for convenience. But such numerical library wrappers might
be reused for BFL and KDL, so the maintainance work is alleviated...
Thoughts?
Klaas
[Bug 666] Adding dynamics primitives and algorithms
On Tue, Jun 16, 2009 at 3:05 PM, Klaas Gadeyne<klaas [dot] gadeyne [..] ...> wrote:
> On Tue, Jun 16, 2009 at 1:53 PM, Stephen Roderick<kiwi [dot] net [..] ...> wrote:
>> On Jun 16, 2009, at 07:10 , Ruben Smits wrote:
>>
>>> On Mon, Jun 15, 2009 at 6:09 PM, S Roderick<kiwi [dot] net [..] ...> wrote:
>>>> On Jun 9, 2009, at 09:18 , Stephen Roderick wrote:
>>>>
>>>>> [pushing back to ML]
>>>>>
>>>>> On Jun 9, 2009, at 08:58 , Ruben Smits wrote:
>>>>>
>>>>>> eigen2 is a full header template library (just like
>>>>>> boost::numeric::ublas), and is more performant than boost.
>>>>>> ubuntu/debian packages are available.
>>>>>>
>>>>>> Ruben
>>>>>>
>>>>>> On Tue, Jun 9, 2009 at 1:13 PM, S Roderick<kiwi [dot] net [..] ...> wrote:
>>>>>>> On Jun 9, 2009, at 05:28 , Ruben Smits wrote:
>>>>>>>
>>>>>>>> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=666
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --- Comment #1 from Ruben Smits <ruben [dot] smits [..] ...>
>>>>>>>> 2009-06-09 11:28:01 ---
>>>>>>>> Created an attachment (id=441)
>>>>>>>> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=441)
>>>>>>>> adds dynamics primitives and algorithm
>>>>>>>>
>>>>>>>> If no-one has any objections this patch goes in soon. It adds a
>>>>>>>> dependency to
>>>>>>>> Eigen2. The idea is to completely switch all dependencies on
>>>>>>>> boost::numeric::ublas to Eigen2.
>>>>>>>
>>>>>>> Is Eigen generally available in most distribution's package
>>>>>>> managers?
>>>>>>> I would hate for this change to make it *harder* to satisfy
>>>>>>> dependancies.
>>>>>>>
>>>>>
>>>>> It is also available in Macports.
>>>>>
>>>>> I just wanted to bring it up to make others aware. We're hitting
>>>>> more
>>>>> resistance from customers, with larger open-source packages
>>>>> containing
>>>>> significant numbers of dependancies.
>>>>
>>>> Just so people know, eigen2 is not avaliable in Ubuntu until
>>>> Intrepid.
>>>>
>>>> It also is not available Debian Lenny, and can't be built with the
>>>> current version of cmake available in Debian Lenny (2.6.0, it needs
>>>> at
>>>> least 2.6.2). So you'll have to source build CMake first, before
>>>> source building Eigen2
>>>
>>> You do not need to compile Eigen2, so just getting the sources and
>>> putting it somewhere on your system should be enough.
>>
>> Good to know! That definitely simplifies the problem.
>>
>>>> Is there no way to continue to support the boost library?
>>>>
>>>
>>> I could put the Eigen2 sources in the KDL-tree, if this helps you.
>>
>> I would personally lean away from this, as I'd rather not be tied to a
>> specific version within a KDL release, and it adds extra maintenance
>> for the KDL folks. YMMV.
>>
>> I'm not against the use of Eigen, just trying to reduce the overhead
>> when using KDL.
>
> I second Stephen in this discussion. Some thoughts:
>
> $ fink show-deps eigen2
> Information about 9070 packages read in 1 seconds.
>
> Package: eigen2 (2.0.2-1)
> To install the compiled package...
> The following other packages (and their dependencies) must be installed:
> [none]
> The following other packages must not be installed:
> [none]
> To compile this package from source...
> The following packages are also compiled at the same time:
> [none]
> The following other packages (and their dependencies) must be installed:
> cmake (>= 2.6.2)
> The following other packages must not be installed:
> [none]
>
> So there is also a dependency on cmake > 2.6.2. Which seems strange
> for a header only package...
>From the Eigen website:
Requirements
Eigen doesn't have any dependency. It just uses a little the C++
standard library.
It uses the CMake build system. However, this is only to build the
documentation and unit-tests, and to automate installation. If you
just want to use Eigen, you can use the header files right away. There
is no binary library to link to (pure template library), and no
configured header file.
> About including this in KDL: AFAIK there have been some thoughts
> about using eigen2 for BFL too. Which leads me to two additional
> thoughts:
> - If eigen2 ain't a header only library, including eigen2 into KDL
> will lead to double symbols for applications that use both BFL
> (wrapping eigen2) and KDL.
Eigen2 _is_ a header only library!
> - A long time ago, the matrix library was not an integral part of BFL
> but a separate library. Since it was only used in BFL, it was
> included for convenience. But such numerical library wrappers might
> be reused for BFL and KDL, so the maintainance work is alleviated...
The matrix wrapper far from realtime safe, that's the main reason why
KDL does not use it.
I think it is possible to get more of the matrix calculations in BFL
realtime safe if you can get rid of the matrix wrapper and pick a
realtime capable matrix library and directly use it's realtime safe
functionality, without having to go through a matrix wrapper.
Ruben
[Bug 666] Adding dynamics primitives and algorithms
On Tue, Jun 16, 2009 at 3:29 PM, Ruben
Smits<ruben [dot] smits [..] ...> wrote:
[...]
> The matrix wrapper far from realtime safe, that's the main reason why
> KDL does not use it.
> I think it is possible to get more of the matrix calculations in BFL
> realtime safe if you can get rid of the matrix wrapper and pick a
> realtime capable matrix library and directly use it's realtime safe
> functionality, without having to go through a matrix wrapper.
I don't see an immediate reason why the matrix wrapper library
(itself) could not be real-time safe? If not, I personally would
prefer that the bug is solved
(see <https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=479>)
instead of just taking a separate path for the matrix libraries in
both orocos subprojects. The assert discussion on this ML yesterday
already gave me a "been there, done that" feeling for the BFL
subproject. Personally I think that OTOneH the orocos subprojects
should be as decoupled as possible in terms of "scope", however
OTOtherH they should work towards reuse and common infrastructure
(coding style, common libraries) as _much_ as possible.
Klaas
[Bug 666] Adding dynamics primitives and algorithms
On Tue, Jun 16, 2009 at 4:00 PM, Klaas Gadeyne<klaas [dot] gadeyne [..] ...> wrote:
> On Tue, Jun 16, 2009 at 3:29 PM, Ruben
> Smits<ruben [dot] smits [..] ...> wrote:
>
> [...]
>> The matrix wrapper far from realtime safe, that's the main reason why
>> KDL does not use it.
>> I think it is possible to get more of the matrix calculations in BFL
>> realtime safe if you can get rid of the matrix wrapper and pick a
>> realtime capable matrix library and directly use it's realtime safe
>> functionality, without having to go through a matrix wrapper.
>
> I don't see an immediate reason why the matrix wrapper library
> (itself) could not be real-time safe?
AFAIK all of the matrix/vector and matrix/matrix multiplications in
the matrix wrapper do dynamic memory allocation.
> If not, I personally would
> prefer that the bug is solved
> (see <https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=479>)
> instead of just taking a separate path for the matrix libraries in
> both orocos subprojects. The assert discussion on this ML yesterday
> already gave me a "been there, done that" feeling for the BFL
> subproject. Personally I think that OTOneH the orocos subprojects
> should be as decoupled as possible in terms of "scope", however
> OTOtherH they should work towards reuse and common infrastructure
> (coding style, common libraries) as _much_ as possible.
We could all use the common matrix library Eigen ;)
Ruben
[Bug 666] Adding dynamics primitives and algorithms
On Tuesday 16 June 2009 16:28:34 Ruben Smits wrote:
> On Tue, Jun 16, 2009 at 4:00 PM, Klaas Gadeyne<klaas [dot] gadeyne [..] ...>
wrote:
> > On Tue, Jun 16, 2009 at 3:29 PM, Ruben
> > Smits<ruben [dot] smits [..] ...> wrote:
> >
> > [...]
> >
> >> The matrix wrapper far from realtime safe, that's the main reason why
> >> KDL does not use it.
> >> I think it is possible to get more of the matrix calculations in BFL
> >> realtime safe if you can get rid of the matrix wrapper and pick a
> >> realtime capable matrix library and directly use it's realtime safe
> >> functionality, without having to go through a matrix wrapper.
> >
> > I don't see an immediate reason why the matrix wrapper library
> > (itself) could not be real-time safe?
agree
>
> AFAIK all of the matrix/vector and matrix/matrix multiplications in
> the matrix wrapper do dynamic memory allocation.
True, but the matrix wrapper could be rewritten such that it can be realtime
safe for realtime safe matrix libs. I even believe the work to get the
matrixwrapper realtime safe is not tremendous, we just have to find someone
willing to do it.
> > If not, I personally would
> > prefer that the bug is solved
> > (see <https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=479>)
> > instead of just taking a separate path for the matrix libraries in
> > both orocos subprojects. The assert discussion on this ML yesterday
> > already gave me a "been there, done that" feeling for the BFL
> > subproject. Personally I think that OTOneH the orocos subprojects
> > should be as decoupled as possible in terms of "scope", however
> > OTOtherH they should work towards reuse and common infrastructure
> > (coding style, common libraries) as _much_ as possible.
I agree!
I prefer one of the two following solutions:
* header only dependancy not bundled with KDL/BFL.
* independent matrix wrapper with support for ublas, eigen2, and other ....
(can be reused for both KDL and BFL).
> We could all use the common matrix library Eigen ;)
Or write a wrapper for which we provide Eigen support and leave it free for
any future developers/contributers to make support for boost or other
libraries.
>
Tinne
[Bug 666] Adding dynamics primitives and algorithms
On Tue, Jun 16, 2009 at 5:08 PM, Tinne De Laet <
tinne [dot] delaet [..] ...> wrote:
> On Tuesday 16 June 2009 16:28:34 Ruben Smits wrote:
> > On Tue, Jun 16, 2009 at 4:00 PM, Klaas Gadeyne<klaas [dot] gadeyne [..] ...>
> wrote:
> > > On Tue, Jun 16, 2009 at 3:29 PM, Ruben
> > > Smits<ruben [dot] smits [..] ...> wrote:
> > >
> > > [...]
> > >
> > >> The matrix wrapper far from realtime safe, that's the main reason why
> > >> KDL does not use it.
> > >> I think it is possible to get more of the matrix calculations in BFL
> > >> realtime safe if you can get rid of the matrix wrapper and pick a
> > >> realtime capable matrix library and directly use it's realtime safe
> > >> functionality, without having to go through a matrix wrapper.
> > >
> > > I don't see an immediate reason why the matrix wrapper library
> > > (itself) could not be real-time safe?
> agree
> >
> > AFAIK all of the matrix/vector and matrix/matrix multiplications in
> > the matrix wrapper do dynamic memory allocation.
> True, but the matrix wrapper could be rewritten such that it can be
> realtime
> safe for realtime safe matrix libs. I even believe the work to get the
> matrixwrapper realtime safe is not tremendous, we just have to find someone
> willing to do it.
>
> > > If not, I personally would
> > > prefer that the bug is solved
> > > (see <https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=479>)
> > > instead of just taking a separate path for the matrix libraries in
> > > both orocos subprojects. The assert discussion on this ML yesterday
> > > already gave me a "been there, done that" feeling for the BFL
> > > subproject. Personally I think that OTOneH the orocos subprojects
> > > should be as decoupled as possible in terms of "scope", however
> > > OTOtherH they should work towards reuse and common infrastructure
> > > (coding style, common libraries) as _much_ as possible.
> I agree!
>
> I prefer one of the two following solutions:
>
> * header only dependancy not bundled with KDL/BFL.
> * independent matrix wrapper with support for ublas, eigen2, and other ....
> (can be reused for both KDL and BFL).
>
>
> > We could all use the common matrix library Eigen ;)
> Or write a wrapper for which we provide Eigen support and leave it free for
> any future developers/contributers to make support for boost or other
> libraries.
I'm a bit cautious about wrappers (I'm not saying I'm against them, though),
because libraries with different APIs and philosophies (e.g., C-based vs.
heavily templated) may not accommodate well into a single wrapper. In this
particular case, the ease eigen provides for manipulating expressions
(component/column/row-wise operations), algorithms (in-place vs. creating a
new instance) and more is something I haven't seen in other libs, and (apart
from its performance) is what makes it really nice to use.
What I'm trying to say is that cool things that one lib provides may not be
available in some other one, and hence may end up being excluded from the
wrapper.
Eager to read some opinions on this...
Adolfo.
>
> >
> Tinne
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
[Bug 666] Adding dynamics primitives and algorithms
2009/6/16 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...>:
>
>
> On Tue, Jun 16, 2009 at 5:08 PM, Tinne De Laet
> <tinne [dot] delaet [..] ...> wrote:
>>
>> On Tuesday 16 June 2009 16:28:34 Ruben Smits wrote:
>> > On Tue, Jun 16, 2009 at 4:00 PM, Klaas Gadeyne<klaas [dot] gadeyne [..] ...>
>> wrote:
>> > > On Tue, Jun 16, 2009 at 3:29 PM, Ruben
>> > > Smits<ruben [dot] smits [..] ...> wrote:
>> > >
>> > > [...]
>> > >
>> > >> The matrix wrapper far from realtime safe, that's the main reason why
>> > >> KDL does not use it.
>> > >> I think it is possible to get more of the matrix calculations in BFL
>> > >> realtime safe if you can get rid of the matrix wrapper and pick a
>> > >> realtime capable matrix library and directly use it's realtime safe
>> > >> functionality, without having to go through a matrix wrapper.
>> > >
>> > > I don't see an immediate reason why the matrix wrapper library
>> > > (itself) could not be real-time safe?
>> agree
>> >
>> > AFAIK all of the matrix/vector and matrix/matrix multiplications in
>> > the matrix wrapper do dynamic memory allocation.
>> True, but the matrix wrapper could be rewritten such that it can be
>> realtime
>> safe for realtime safe matrix libs. I even believe the work to get the
>> matrixwrapper realtime safe is not tremendous, we just have to find
>> someone
>> willing to do it.
>>
>> > > If not, I personally would
>> > > prefer that the bug is solved
>> > > (see <https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=479>)
>> > > instead of just taking a separate path for the matrix libraries in
>> > > both orocos subprojects. The assert discussion on this ML yesterday
>> > > already gave me a "been there, done that" feeling for the BFL
>> > > subproject. Personally I think that OTOneH the orocos subprojects
>> > > should be as decoupled as possible in terms of "scope", however
>> > > OTOtherH they should work towards reuse and common infrastructure
>> > > (coding style, common libraries) as _much_ as possible.
>> I agree!
>>
>> I prefer one of the two following solutions:
>>
>> * header only dependancy not bundled with KDL/BFL.
>> * independent matrix wrapper with support for ublas, eigen2, and other
>> ....
>> (can be reused for both KDL and BFL).
>>
>>
>> > We could all use the common matrix library Eigen ;)
>> Or write a wrapper for which we provide Eigen support and leave it free
>> for
>> any future developers/contributers to make support for boost or other
>> libraries.
>
> I'm a bit cautious about wrappers (I'm not saying I'm against them, though),
> because libraries with different APIs and philosophies (e.g., C-based vs.
> heavily templated) may not accommodate well into a single wrapper. In this
> particular case, the ease eigen provides for manipulating expressions
> (component/column/row-wise operations), algorithms (in-place vs. creating a
> new instance) and more is something I haven't seen in other libs, and (apart
> from its performance) is what makes it really nice to use.
>
> What I'm trying to say is that cool things that one lib provides may not be
> available in some other one, and hence may end up being excluded from the
> wrapper.
> Eager to read some opinions on this...
I fully agree on this. There is stuff in Eigen that I/we would want to
use for efficiency reasons but which is not available in other matrix
libraries. If you/I/we/some-one ends up writing wrapper functions for
all this cool, but matrix library specific, features, you might end up
loosing efficiency.
Both boost::numeric::ublas and Eigen2 efficiency relies heavily on
template expressions, this makes them very different in use compared
with LTI or NewMat. Creating a matrix wrapper that works with all four
of them and still offers the nice features of boost::numeric::ublas or
Eigen2, will be a though job, that might not be worth doing IMHO.
What's so difficult in doing a benchmark and pick the best matrix library?
Ruben
[Bug 666] Adding dynamics primitives and algorithms
On Tue, Jun 16, 2009 at 8:48 PM, Ruben
Smits<ruben [dot] smits [..] ...> wrote:
[...]
>> I'm a bit cautious about wrappers (I'm not saying I'm against them, though),
>> because libraries with different APIs and philosophies (e.g., C-based vs.
>> heavily templated) may not accommodate well into a single wrapper. In this
>> particular case, the ease eigen provides for manipulating expressions
>> (component/column/row-wise operations), algorithms (in-place vs. creating a
>> new instance) and more is something I haven't seen in other libs, and (apart
>> from its performance) is what makes it really nice to use.
>>
>> What I'm trying to say is that cool things that one lib provides may not be
>> available in some other one, and hence may end up being excluded from the
>> wrapper.
>> Eager to read some opinions on this...
>
> I fully agree on this. There is stuff in Eigen that I/we would want to
> use for efficiency reasons but which is not available in other matrix
> libraries. If you/I/we/some-one ends up writing wrapper functions for
> all this cool, but matrix library specific, features, you might end up
> loosing efficiency.
I think both BFL and RTT (OS abstraction) prove that wrappers _do_
have advantages. Testing wether a bug is in a dependency or in your
own code (naaaaaaaH) for instance. And being able to select the best
dependency _for a given job_ (note that the "best" is related to "a
given job" in this statement).
I some library doesn't provide a particular algorithm, then either
leave it unimplemented or use a less efficiently implemented default.
> Both boost::numeric::ublas and Eigen2 efficiency relies heavily on
> template expressions, this makes them very different in use compared
> with LTI or NewMat. Creating a matrix wrapper that works with all four
> of them and still offers the nice features of boost::numeric::ublas or
> Eigen2, will be a though job, that might not be worth doing IMHO.
Might be true. I haven't looked at their APIs. That is something to
take into consideration for sure. Although the advantage of a wrapper
library could also be that you are _forced_ to keep the dependencies
to a particular library to a minimum.
> What's so difficult in doing a benchmark and pick the best matrix library?
What's so difficult in doing a benchmark and selecting the best
inverse kinematic solver algorithm?
What's so difficult in doing a benchmark and selecting the best RTOS for RTT?
If it would be so simple, there wouldn't be 1000 c++ matrix library
implementations around don't you think? What will you do if library A
is the "best" for KDL algorithm AA en library B is the "best" for KDL
algorithm BB?
Klaas
[Bug 666] Adding dynamics primitives and algorithms
On Wed, Jun 17, 2009 at 9:37 AM, Klaas Gadeyne <klaas [dot] gadeyne [..] ...>wrote:
> On Tue, Jun 16, 2009 at 8:48 PM, Ruben
> Smits<ruben [dot] smits [..] ...> wrote:
> [...]
> >> I'm a bit cautious about wrappers (I'm not saying I'm against them,
> though),
> >> because libraries with different APIs and philosophies (e.g., C-based
> vs.
> >> heavily templated) may not accommodate well into a single wrapper. In
> this
> >> particular case, the ease eigen provides for manipulating expressions
> >> (component/column/row-wise operations), algorithms (in-place vs.
> creating a
> >> new instance) and more is something I haven't seen in other libs, and
> (apart
> >> from its performance) is what makes it really nice to use.
> >>
> >> What I'm trying to say is that cool things that one lib provides may not
> be
> >> available in some other one, and hence may end up being excluded from
> the
> >> wrapper.
> >> Eager to read some opinions on this...
> >
> > I fully agree on this. There is stuff in Eigen that I/we would want to
> > use for efficiency reasons but which is not available in other matrix
> > libraries. If you/I/we/some-one ends up writing wrapper functions for
> > all this cool, but matrix library specific, features, you might end up
> > loosing efficiency.
>
> I think both BFL and RTT (OS abstraction) prove that wrappers _do_
> have advantages. Testing wether a bug is in a dependency or in your
> own code (naaaaaaaH) for instance. And being able to select the best
> dependency _for a given job_ (note that the "best" is related to "a
> given job" in this statement).
> I some library doesn't provide a particular algorithm, then either
> leave it unimplemented or use a less efficiently implemented default.
>
> > Both boost::numeric::ublas and Eigen2 efficiency relies heavily on
> > template expressions, this makes them very different in use compared
> > with LTI or NewMat. Creating a matrix wrapper that works with all four
> > of them and still offers the nice features of boost::numeric::ublas or
> > Eigen2, will be a though job, that might not be worth doing IMHO.
>
> Might be true. I haven't looked at their APIs. That is something to
> take into consideration for sure. Although the advantage of a wrapper
> library could also be that you are _forced_ to keep the dependencies
> to a particular library to a minimum.
Apart from both being heavily template-based, is there any experienced user
of both ublas and eigen2 that can share some comments on the feasibility of
a common wrapper for both?
Also, what library functionalities are envisaged to be used by the different
Orocos subprojects? This would also help in delimiting what needs to be
wrapped and what not.
I'm referring to things like dynamic and/or statically allocated
vectors/matrices, matrix decomposition algos (Cholesky, SVD, ...).
Also, it is worth mentioning that eigen2 implements things like geometry
primitives (quaternions, rigid transformations, hyperplanes/lines) and is in
the process of implementing basic statistical functionalities. AFAIK, ublas
does not provide these (and for that matter, I know of no other library that
provides them). If such functionality is required by the Orocos subprojects,
would it be of interest to use upstream developed alternatives? (sounds
tempting...)
I have little experience with boost::numeric::ublas and I'm quite new to
eigen, so I currently don't have a strong opinion on this. Also, I remain
open to consider other implementations.
Adolfo.
>
>
> > What's so difficult in doing a benchmark and pick the best matrix
> library?
>
> What's so difficult in doing a benchmark and selecting the best
> inverse kinematic solver algorithm?
> What's so difficult in doing a benchmark and selecting the best RTOS for
> RTT?
> If it would be so simple, there wouldn't be 1000 c++ matrix library
> implementations around don't you think? What will you do if library A
> is the "best" for KDL algorithm AA en library B is the "best" for KDL
> algorithm BB?
>
> Klaas
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
[Bug 666] Adding dynamics primitives and algorithms
On Wed, 17 Jun 2009, Adolfo Rodríguez Tsouroukdissian wrote:
[...]
> Also, what library functionalities are envisaged to be used by the different
> Orocos subprojects? This would also help in delimiting what needs to be
> wrapped and what not.
> I'm referring to things like dynamic and/or statically allocated
> vectors/matrices, matrix decomposition algos (Cholesky, SVD, ...).
Orocos/KDL will need the traditional matrix/vector multiplications and
SVD-based algorithms. Of this I am rather confident.
Orocos/BFL will probably need the same functionalities, since the
statistical functionalities will come from elsewhere. Of this I am not so
confident.
> Also, it is worth mentioning that eigen2 implements things like geometry
> primitives (quaternions, rigid transformations, hyperplanes/lines) and is in
> the process of implementing basic statistical functionalities. AFAIK, ublas
> does not provide these (and for that matter, I know of no other library that
> provides them). If such functionality is required by the Orocos subprojects,
> would it be of interest to use upstream developed alternatives? (sounds
> tempting...)
Indeed! But we have no 100% clear view or position on this.
> I have little experience with boost::numeric::ublas and I'm quite new to
> eigen, so I currently don't have a strong opinion on this. Also, I remain
> open to consider other implementations.
>
Orocos has one very strict constraint: realtime use should not be
prevented. That leaves very few options...
Herman
[Bug 666] Adding dynamics primitives and algorithms
[...]
> >
> > I'm a bit cautious about wrappers (I'm not saying I'm against them,
> > though), because libraries with different APIs and philosophies (e.g.,
> > C-based vs. heavily templated) may not accommodate well into a single
> > wrapper. In this particular case, the ease eigen provides for
> > manipulating expressions (component/column/row-wise operations),
> > algorithms (in-place vs. creating a new instance) and more is something I
> > haven't seen in other libs, and (apart from its performance) is what
> > makes it really nice to use.
> >
> > What I'm trying to say is that cool things that one lib provides may not
> > be available in some other one, and hence may end up being excluded from
> > the wrapper.
> > Eager to read some opinions on this...
>
> I fully agree on this. There is stuff in Eigen that I/we would want to
> use for efficiency reasons but which is not available in other matrix
> libraries. If you/I/we/some-one ends up writing wrapper functions for
> all this cool, but matrix library specific, features, you might end up
> loosing efficiency.
Mmm, true.
>
> Both boost::numeric::ublas and Eigen2 efficiency relies heavily on
> template expressions, this makes them very different in use compared
> with LTI or NewMat. Creating a matrix wrapper that works with all four
> of them and still offers the nice features of boost::numeric::ublas or
> Eigen2, will be a though job, that might not be worth doing IMHO.
I prefer not to continue support for LTI, since the project seems quite
dead,... Their latest release does not compile anymore, I made a patch to make
it work again, but it was not included yet by the LTI developers (they are
waiting their new release ... )
How about starting with a wrapper which would support Boost and Eigen2?
Using a wrapper would make it easier when in the future a new even nicer
matrix library is released... (would be a pain when the eigen2 code is
embedded in the KLD/BFL code).
Anyone any estimate abouth the possible efficiency loss when making a wrapper
for Boost and Eigen2?
Tinne
[Bug 666] Adding dynamics primitives and algorithms
On Tue, 16 Jun 2009, Ruben Smits wrote:
[...]
> What's so difficult in doing a benchmark and pick the best matrix library?
Because different libraries will score best in different parts of the
benchmark... And there are other than pure performance reasons why a
library is chosen to depend on or not.
Herman
[Bug 666] Adding dynamics primitives and algorithms
On Tue, Jun 16, 2009 at 3:05 PM, Klaas Gadeyne <klaas [dot] gadeyne [..] ...>wrote:
> On Tue, Jun 16, 2009 at 1:53 PM, Stephen Roderick<kiwi [dot] net [..] ...> wrote:
> > On Jun 16, 2009, at 07:10 , Ruben Smits wrote:
> >
> >> On Mon, Jun 15, 2009 at 6:09 PM, S Roderick<kiwi [dot] net [..] ...> wrote:
> >>> On Jun 9, 2009, at 09:18 , Stephen Roderick wrote:
> >>>
> >>>> [pushing back to ML]
> >>>>
> >>>> On Jun 9, 2009, at 08:58 , Ruben Smits wrote:
> >>>>
> >>>>> eigen2 is a full header template library (just like
> >>>>> boost::numeric::ublas), and is more performant than boost.
> >>>>> ubuntu/debian packages are available.
> >>>>>
> >>>>> Ruben
> >>>>>
> >>>>> On Tue, Jun 9, 2009 at 1:13 PM, S Roderick<kiwi [dot] net [..] ...> wrote:
> >>>>>> On Jun 9, 2009, at 05:28 , Ruben Smits wrote:
> >>>>>>
> >>>>>>> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=666
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --- Comment #1 from Ruben Smits <ruben [dot] smits [..] ...>
> >>>>>>> 2009-06-09 11:28:01 ---
> >>>>>>> Created an attachment (id=441)
> >>>>>>> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=441)
> >>>>>>> adds dynamics primitives and algorithm
> >>>>>>>
> >>>>>>> If no-one has any objections this patch goes in soon. It adds a
> >>>>>>> dependency to
> >>>>>>> Eigen2. The idea is to completely switch all dependencies on
> >>>>>>> boost::numeric::ublas to Eigen2.
> >>>>>>
> >>>>>> Is Eigen generally available in most distribution's package
> >>>>>> managers?
> >>>>>> I would hate for this change to make it *harder* to satisfy
> >>>>>> dependancies.
> >>>>>>
> >>>>
> >>>> It is also available in Macports.
> >>>>
> >>>> I just wanted to bring it up to make others aware. We're hitting
> >>>> more
> >>>> resistance from customers, with larger open-source packages
> >>>> containing
> >>>> significant numbers of dependancies.
> >>>
> >>> Just so people know, eigen2 is not avaliable in Ubuntu until
> >>> Intrepid.
> >>>
> >>> It also is not available Debian Lenny, and can't be built with the
> >>> current version of cmake available in Debian Lenny (2.6.0, it needs
> >>> at
> >>> least 2.6.2). So you'll have to source build CMake first, before
> >>> source building Eigen2
> >>
> >> You do not need to compile Eigen2, so just getting the sources and
> >> putting it somewhere on your system should be enough.
> >
> > Good to know! That definitely simplifies the problem.
> >
> >>> Is there no way to continue to support the boost library?
> >>>
> >>
> >> I could put the Eigen2 sources in the KDL-tree, if this helps you.
> >
> > I would personally lean away from this, as I'd rather not be tied to a
> > specific version within a KDL release, and it adds extra maintenance
> > for the KDL folks. YMMV.
> >
> > I'm not against the use of Eigen, just trying to reduce the overhead
> > when using KDL.
>
> I second Stephen in this discussion. Some thoughts:
>
> $ fink show-deps eigen2
> Information about 9070 packages read in 1 seconds.
>
> Package: eigen2 (2.0.2-1)
> To install the compiled package...
> The following other packages (and their dependencies) must be installed:
> [none]
> The following other packages must not be installed:
> [none]
> To compile this package from source...
> The following packages are also compiled at the same time:
> [none]
> The following other packages (and their dependencies) must be installed:
> cmake (>= 2.6.2)
> The following other packages must not be installed:
> [none]
>
> So there is also a dependency on cmake > 2.6.2. Which seems strange
> for a header only package...
>From the eigen project page:
"Eigen doesn't have any dependency. It just uses a little the C++ standard
library. It uses the CMake build system. However, this is only to build the
documentation and unit-tests, and to automate installation. If you just want
to use Eigen, you can use the header files right away."
>
> About including this in KDL: AFAIK there have been some thoughts
> about using eigen2 for BFL too. Which leads me to two additional
> thoughts:
> - If eigen2 ain't a header only library, including eigen2 into KDL
> will lead to double symbols for applications that use both BFL
> (wrapping eigen2) and KDL.
> - A long time ago, the matrix library was not an integral part of BFL
> but a separate library. Since it was only used in BFL, it was
> included for convenience. But such numerical library wrappers might
> be reused for BFL and KDL, so the maintainance work is alleviated...
>
> Thoughts?
Count me +1for adding the dependency and not bundling anything with KDL (or
BFL). I don't think it'll be much of a hassle to copy a folder of headers in
the case your distro does not package eigen :)
Adolfo.
>
>
> Klaas
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
[Bug 666] Adding dynamics primitives and algorithms
A Dimarts 16 Juny 2009, Adolfo Rodríguez Tsouroukdissian va escriure:
> On Tue, Jun 16, 2009 at 3:05 PM, Klaas Gadeyne
<klaas [dot] gadeyne [..] ...>wrote:
> > On Tue, Jun 16, 2009 at 1:53 PM, Stephen Roderick<kiwi [dot] net [..] ...> wrote:
> > > On Jun 16, 2009, at 07:10 , Ruben Smits wrote:
[...]
> >
> > Thoughts?
>
> Count me +1for adding the dependency and not bundling anything with KDL (or
> BFL). I don't think it'll be much of a hassle to copy a folder of headers
> in the case your distro does not package eigen :)
One simple solution is to have a copy of eigen directory with the source code.
Then some cmake macro flag (and finder) to search if the system has eigen. If
the system has eigen installed, use it (if the developer wants) and if not
found (or the developer doesn't want) use the copy from the tree.
Leo
[Bug 666] Adding dynamics primitives and algorithms
On Jun 16, 2009, at 09:21 , Adolfo Rodríguez Tsouroukdissian wrote:
>
>
> On Tue, Jun 16, 2009 at 3:05 PM, Klaas Gadeyne <klaas [dot] gadeyne [..] ...
> > wrote:
> On Tue, Jun 16, 2009 at 1:53 PM, Stephen Roderick<kiwi [dot] net [..] ...>
> wrote:
> > On Jun 16, 2009, at 07:10 , Ruben Smits wrote:
> >
> >> On Mon, Jun 15, 2009 at 6:09 PM, S Roderick<kiwi [dot] net [..] ...>
> wrote:
> >>> On Jun 9, 2009, at 09:18 , Stephen Roderick wrote:
> >>>
> >>>> [pushing back to ML]
> >>>>
> >>>> On Jun 9, 2009, at 08:58 , Ruben Smits wrote:
> >>>>
> >>>>> eigen2 is a full header template library (just like
> >>>>> boost::numeric::ublas), and is more performant than boost.
> >>>>> ubuntu/debian packages are available.
> >>>>>
> >>>>> Ruben
> >>>>>
> >>>>> On Tue, Jun 9, 2009 at 1:13 PM, S Roderick<kiwi [dot] net [..] ...>
> wrote:
> >>>>>> On Jun 9, 2009, at 05:28 , Ruben Smits wrote:
> >>>>>>
> >>>>>>> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=666
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --- Comment #1 from Ruben Smits <ruben [dot] smits [..] ...>
> >>>>>>> 2009-06-09 11:28:01 ---
> >>>>>>> Created an attachment (id=441)
> >>>>>>> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?
> id=441)
> >>>>>>> adds dynamics primitives and algorithm
> >>>>>>>
> >>>>>>> If no-one has any objections this patch goes in soon. It
> adds a
> >>>>>>> dependency to
> >>>>>>> Eigen2. The idea is to completely switch all dependencies on
> >>>>>>> boost::numeric::ublas to Eigen2.
> >>>>>>
> >>>>>> Is Eigen generally available in most distribution's package
> >>>>>> managers?
> >>>>>> I would hate for this change to make it *harder* to satisfy
> >>>>>> dependancies.
> >>>>>>
> >>>>
> >>>> It is also available in Macports.
> >>>>
> >>>> I just wanted to bring it up to make others aware. We're hitting
> >>>> more
> >>>> resistance from customers, with larger open-source packages
> >>>> containing
> >>>> significant numbers of dependancies.
> >>>
> >>> Just so people know, eigen2 is not avaliable in Ubuntu until
> >>> Intrepid.
> >>>
> >>> It also is not available Debian Lenny, and can't be built with the
> >>> current version of cmake available in Debian Lenny (2.6.0, it
> needs
> >>> at
> >>> least 2.6.2). So you'll have to source build CMake first, before
> >>> source building Eigen2
> >>
> >> You do not need to compile Eigen2, so just getting the sources and
> >> putting it somewhere on your system should be enough.
> >
> > Good to know! That definitely simplifies the problem.
> >
> >>> Is there no way to continue to support the boost library?
> >>>
> >>
> >> I could put the Eigen2 sources in the KDL-tree, if this helps you.
> >
> > I would personally lean away from this, as I'd rather not be tied
> to a
> > specific version within a KDL release, and it adds extra maintenance
> > for the KDL folks. YMMV.
> >
> > I'm not against the use of Eigen, just trying to reduce the overhead
> > when using KDL.
>
> I second Stephen in this discussion. Some thoughts:
>
> $ fink show-deps eigen2
> Information about 9070 packages read in 1 seconds.
>
> Package: eigen2 (2.0.2-1)
> To install the compiled package...
> The following other packages (and their dependencies) must be
> installed:
> [none]
> The following other packages must not be installed:
> [none]
> To compile this package from source...
> The following packages are also compiled at the same time:
> [none]
> The following other packages (and their dependencies) must be
> installed:
> cmake (>= 2.6.2)
> The following other packages must not be installed:
> [none]
>
> So there is also a dependency on cmake > 2.6.2. Which seems strange
> for a header only package...
>
> From the eigen project page:
> "Eigen doesn't have any dependency. It just uses a little the C++
> standard library. It uses the CMake build system. However, this is
> only to build the documentation and unit-tests, and to automate
> installation. If you just want to use Eigen, you can use the header
> files right away."
>
>
>
>
> About including this in KDL: AFAIK there have been some thoughts
> about using eigen2 for BFL too. Which leads me to two additional
> thoughts:
> - If eigen2 ain't a header only library, including eigen2 into KDL
> will lead to double symbols for applications that use both BFL
> (wrapping eigen2) and KDL.
> - A long time ago, the matrix library was not an integral part of BFL
> but a separate library. Since it was only used in BFL, it was
> included for convenience. But such numerical library wrappers might
> be reused for BFL and KDL, so the maintainance work is alleviated...
>
> Thoughts?
>
> Count me +1for adding the dependency and not bundling anything with
> KDL (or BFL). I don't think it'll be much of a hassle to copy a
> folder of headers in the case your distro does not package eigen :)
+1 for header only dependancy not bundled with KDL/BFL.
We just need to ensure we let future users know that you don't need to
actually build this dependancy, should it not be packaged with your
distro. Particularly as when I tried building the damn thing it blew
up anyway!! :-(
Do we explicitly list dependancies for each project? I don't remember
seeing that kind of list ...
S
[Bug 666] Adding dynamics primitives and algorithms
2009/6/16 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...>:
>
>
> On Mon, Jun 15, 2009 at 6:09 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
>>
>> On Jun 9, 2009, at 09:18 , Stephen Roderick wrote:
>>
>> > [pushing back to ML]
>> >
>> > On Jun 9, 2009, at 08:58 , Ruben Smits wrote:
>> >
>> >> eigen2 is a full header template library (just like
>> >> boost::numeric::ublas), and is more performant than boost.
>> >> ubuntu/debian packages are available.
>> >>
>> >> Ruben
>> >>
>> >> On Tue, Jun 9, 2009 at 1:13 PM, S Roderick<kiwi [dot] net [..] ...> wrote:
>> >>> On Jun 9, 2009, at 05:28 , Ruben Smits wrote:
>> >>>
>> >>>> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=666
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --- Comment #1 from Ruben Smits <ruben [dot] smits [..] ...>
>> >>>> 2009-06-09 11:28:01 ---
>> >>>> Created an attachment (id=441)
>> >>>> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=441)
>> >>>> adds dynamics primitives and algorithm
>> >>>>
>> >>>> If no-one has any objections this patch goes in soon. It adds a
>> >>>> dependency to
>> >>>> Eigen2. The idea is to completely switch all dependencies on
>> >>>> boost::numeric::ublas to Eigen2.
>> >>>
>> >>> Is Eigen generally available in most distribution's package
>> >>> managers?
>> >>> I would hate for this change to make it *harder* to satisfy
>> >>> dependancies.
>> >>>
>> >
>> > It is also available in Macports.
>> >
>> > I just wanted to bring it up to make others aware. We're hitting more
>> > resistance from customers, with larger open-source packages containing
>> > significant numbers of dependancies.
>>
>> Just so people know, eigen2 is not avaliable in Ubuntu until Intrepid.
>>
>> It also is not available Debian Lenny, and can't be built with the
>> current version of cmake available in Debian Lenny (2.6.0, it needs at
>> least 2.6.2). So you'll have to source build CMake first, before
>> source building Eigen2
>>
>> Is there no way to continue to support the boost library?
>
> I for one would like to see eigen2 make it to KDL. If package availability
> is an issue, would you consider including the eigen source (only headers) as
> part of KDL. We could probably do some configure-time logic to select
> between an installed package and, if absent, KDL's own.
I could do this, if there is enough demand for it.
> Also, I've been wondering, if eigen support is implemented, would it be
> through some KDL wrapper classes, or would eigen constructs be allowed in
> the KDL code?
> The former has the advantage of still being able to support other back-ends,
> such as boost::ublas, but may suffer from limiting the power of eigen (ublas
> does not provide _many_ of eigen's cool features and expressive syntax). I
> would be very interested in reading your thoughts on this.
It is the former:
The Eigen usage now only replaces the boost usage. Which means that
Eigen2 in not visible in the external API of KDL, it is only used
internally by some of the primitives/solvers. Most primitives still
use our own representation though.
I'd rather not have wrapper classes for different matrix libraries,
because making a wrapper for all the features we would like to use is
a very extensive work.
Ruben
[Bug 666] Adding dynamics primitives and algorithms
2009/6/16 Ruben Smits <ruben [dot] smits [..] ...>
> 2009/6/16 Adolfo Rodríguez Tsouroukdissian <
> adolfo [dot] rodriguez [..] ...>:
> >
> >
> > On Mon, Jun 15, 2009 at 6:09 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
> >>
> >> On Jun 9, 2009, at 09:18 , Stephen Roderick wrote:
> >>
> >> > [pushing back to ML]
> >> >
> >> > On Jun 9, 2009, at 08:58 , Ruben Smits wrote:
> >> >
> >> >> eigen2 is a full header template library (just like
> >> >> boost::numeric::ublas), and is more performant than boost.
> >> >> ubuntu/debian packages are available.
> >> >>
> >> >> Ruben
> >> >>
> >> >> On Tue, Jun 9, 2009 at 1:13 PM, S Roderick<kiwi [dot] net [..] ...> wrote:
> >> >>> On Jun 9, 2009, at 05:28 , Ruben Smits wrote:
> >> >>>
> >> >>>> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=666
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> --- Comment #1 from Ruben Smits <ruben [dot] smits [..] ...>
> >> >>>> 2009-06-09 11:28:01 ---
> >> >>>> Created an attachment (id=441)
> >> >>>> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=441)
> >> >>>> adds dynamics primitives and algorithm
> >> >>>>
> >> >>>> If no-one has any objections this patch goes in soon. It adds a
> >> >>>> dependency to
> >> >>>> Eigen2. The idea is to completely switch all dependencies on
> >> >>>> boost::numeric::ublas to Eigen2.
> >> >>>
> >> >>> Is Eigen generally available in most distribution's package
> >> >>> managers?
> >> >>> I would hate for this change to make it *harder* to satisfy
> >> >>> dependancies.
> >> >>>
> >> >
> >> > It is also available in Macports.
> >> >
> >> > I just wanted to bring it up to make others aware. We're hitting more
> >> > resistance from customers, with larger open-source packages containing
> >> > significant numbers of dependancies.
> >>
> >> Just so people know, eigen2 is not avaliable in Ubuntu until Intrepid.
> >>
> >> It also is not available Debian Lenny, and can't be built with the
> >> current version of cmake available in Debian Lenny (2.6.0, it needs at
> >> least 2.6.2). So you'll have to source build CMake first, before
> >> source building Eigen2
> >>
> >> Is there no way to continue to support the boost library?
> >
> > I for one would like to see eigen2 make it to KDL. If package
> availability
> > is an issue, would you consider including the eigen source (only headers)
> as
> > part of KDL. We could probably do some configure-time logic to select
> > between an installed package and, if absent, KDL's own.
>
> I could do this, if there is enough demand for it.
>
>
> > Also, I've been wondering, if eigen support is implemented, would it be
> > through some KDL wrapper classes, or would eigen constructs be allowed in
> > the KDL code?
> > The former has the advantage of still being able to support other
> back-ends,
> > such as boost::ublas, but may suffer from limiting the power of eigen
> (ublas
> > does not provide _many_ of eigen's cool features and expressive syntax).
> I
> > would be very interested in reading your thoughts on this.
>
> It is the former:
>
> The Eigen usage now only replaces the boost usage. Which means that
> Eigen2 in not visible in the external API of KDL, it is only used
> internally by some of the primitives/solvers. Most primitives still
> use our own representation though.
>
> I'd rather not have wrapper classes for different matrix libraries,
> because making a wrapper for all the features we would like to use is
> a very extensive work.
Certainly!
I haven't had a chance to dig deeply into KDL's code, but have only sifted
through the proposed patch. I effectively see (sparse) references to
eigen-specific stuff. So, to double-check: are the dynamic allocation issues
inherent to using boost::numeric::ublas not present anymore if the patch
makes it through?, or does this only affect the dynamics primitives-related
additions?
TIA,
Adolfo.
>
> Ruben
>
[Bug 666] Adding dynamics primitives and algorithms
2009/6/16 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...>:
>
>
> 2009/6/16 Ruben Smits <ruben [dot] smits [..] ...>
>>
>> 2009/6/16 Adolfo Rodríguez Tsouroukdissian
>> <adolfo [dot] rodriguez [..] ...>:
>> >
>> >
>> > On Mon, Jun 15, 2009 at 6:09 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
>> >>
>> >> On Jun 9, 2009, at 09:18 , Stephen Roderick wrote:
>> >>
>> >> > [pushing back to ML]
>> >> >
>> >> > On Jun 9, 2009, at 08:58 , Ruben Smits wrote:
>> >> >
>> >> >> eigen2 is a full header template library (just like
>> >> >> boost::numeric::ublas), and is more performant than boost.
>> >> >> ubuntu/debian packages are available.
>> >> >>
>> >> >> Ruben
>> >> >>
>> >> >> On Tue, Jun 9, 2009 at 1:13 PM, S Roderick<kiwi [dot] net [..] ...> wrote:
>> >> >>> On Jun 9, 2009, at 05:28 , Ruben Smits wrote:
>> >> >>>
>> >> >>>> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=666
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> --- Comment #1 from Ruben Smits <ruben [dot] smits [..] ...>
>> >> >>>> 2009-06-09 11:28:01 ---
>> >> >>>> Created an attachment (id=441)
>> >> >>>> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=441)
>> >> >>>> adds dynamics primitives and algorithm
>> >> >>>>
>> >> >>>> If no-one has any objections this patch goes in soon. It adds a
>> >> >>>> dependency to
>> >> >>>> Eigen2. The idea is to completely switch all dependencies on
>> >> >>>> boost::numeric::ublas to Eigen2.
>> >> >>>
>> >> >>> Is Eigen generally available in most distribution's package
>> >> >>> managers?
>> >> >>> I would hate for this change to make it *harder* to satisfy
>> >> >>> dependancies.
>> >> >>>
>> >> >
>> >> > It is also available in Macports.
>> >> >
>> >> > I just wanted to bring it up to make others aware. We're hitting more
>> >> > resistance from customers, with larger open-source packages
>> >> > containing
>> >> > significant numbers of dependancies.
>> >>
>> >> Just so people know, eigen2 is not avaliable in Ubuntu until Intrepid.
>> >>
>> >> It also is not available Debian Lenny, and can't be built with the
>> >> current version of cmake available in Debian Lenny (2.6.0, it needs at
>> >> least 2.6.2). So you'll have to source build CMake first, before
>> >> source building Eigen2
>> >>
>> >> Is there no way to continue to support the boost library?
>> >
>> > I for one would like to see eigen2 make it to KDL. If package
>> > availability
>> > is an issue, would you consider including the eigen source (only
>> > headers) as
>> > part of KDL. We could probably do some configure-time logic to select
>> > between an installed package and, if absent, KDL's own.
>>
>> I could do this, if there is enough demand for it.
>>
>>
>> > Also, I've been wondering, if eigen support is implemented, would it be
>> > through some KDL wrapper classes, or would eigen constructs be allowed
>> > in
>> > the KDL code?
>> > The former has the advantage of still being able to support other
>> > back-ends,
>> > such as boost::ublas, but may suffer from limiting the power of eigen
>> > (ublas
>> > does not provide _many_ of eigen's cool features and expressive syntax).
>> > I
>> > would be very interested in reading your thoughts on this.
>>
>> It is the former:
>>
>> The Eigen usage now only replaces the boost usage. Which means that
>> Eigen2 in not visible in the external API of KDL, it is only used
>> internally by some of the primitives/solvers. Most primitives still
>> use our own representation though.
>>
>> I'd rather not have wrapper classes for different matrix libraries,
>> because making a wrapper for all the features we would like to use is
>> a very extensive work.
>
> Certainly!
>
> I haven't had a chance to dig deeply into KDL's code, but have only sifted
> through the proposed patch. I effectively see (sparse) references to
> eigen-specific stuff. So, to double-check: are the dynamic allocation issues
> inherent to using boost::numeric::ublas not present anymore if the patch
> makes it through?
There were no dynamic allocations with boost::numeric::ublas, Eigen2
is just easier to use, offers a lot of nice features and it should be
faster in the end. I'm setting up a test for speed-comparison.
>, or does this only affect the dynamics primitives-related
> additions?
No, a very few solvers used boost internally, this is replaced by Eigen.
Ruben