Doing some investigation on the internet, seems like this has already
been done, but the pieces are scattered about. First, I saw that BFL has
a typekit in SVN for almost everything BUT eigen:
http://svn.mech.kuleuven.be/repos/orocos/trunk/bfl/src/wrappers/matrix/
But then (in one of the last posts to the BFL mailing list) there was this:
http://lists.mech.kuleuven.be/pipermail/bfl/2011-October/001261.html
Two questions,
1) Is there a repo out there where someone has already applied the eigen
patch to the bfl_typekit?
2) I hate having unneeded dependencies, has anyone, by chance, separated
the vector/matrix typekit from bfl into a standalone thing?
JD
eigen typekit
Am 08.08.2012 um 21:38 schrieb J.D. Yamokoski:
> Doing some investigation on the internet, seems like this has already been done, but the pieces are scattered about. First, I saw that BFL has a typekit in SVN for almost everything BUT eigen:
>
> http://svn.mech.kuleuven.be/repos/orocos/trunk/bfl/src/wrappers/matrix/
>
> But then (in one of the last posts to the BFL mailing list) there was this:
>
> http://lists.mech.kuleuven.be/pipermail/bfl/2011-October/001261.html
>
> Two questions,
>
> 1) Is there a repo out there where someone has already applied the eigen patch to the bfl_typekit?
> 2) I hate having unneeded dependencies, has anyone, by chance, separated the vector/matrix typekit from bfl into a standalone thing?
We are using Eigen 3 together with Rock/OROCOS. The wrappers for this can be found on gitorious.org (http://www.gitorious.org/rock-toolchain/orogen-base-types). But, there is a downside as we are using orogen to automatically generate the typekits during compilation.
In principle you could install a minimal version of rock (www.rock-robotics.org) generate the typekits and copy them into your plain orocos project.
Some more informations about Eigen and Rock/Orocos can be found here: (http://rock.opendfki.de/wiki/WikiStart/Toolchain/EigenTypes)
But maybe there is a better solution out there.
Alex
>
> JD
eigen typekit
On 08/08/2012 10:31 PM, Alexander Duda wrote:
>
> Am 08.08.2012 um 21:38 schrieb J.D. Yamokoski:
>
>> Doing some investigation on the internet, seems like this has already been done, but the pieces are scattered about. First, I saw that BFL has a typekit in SVN for almost
>> everything BUT eigen:
>>
>> http://svn.mech.kuleuven.be/repos/orocos/trunk/bfl/src/wrappers/matrix/
>>
>> But then (in one of the last posts to the BFL mailing list) there was this:
>>
>> http://lists.mech.kuleuven.be/pipermail/bfl/2011-October/001261.html
>>
>> Two questions,
>>
>> 1) Is there a repo out there where someone has already applied the eigen patch to the bfl_typekit?
>> 2) I hate having unneeded dependencies, has anyone, by chance, separated the vector/matrix typekit from bfl into a standalone thing?
>
> We are using Eigen 3 together with Rock/OROCOS. The wrappers for this can be found on gitorious.org <http://gitorious.org>
> (http://www.gitorious.org/rock-toolchain/orogen-base-types). But, there is a downside as we are using orogen to automatically generate the typekits during compilation.
>
> In principle you could install a minimal version of rock (www.rock-robotics.org <http://www.rock-robotics.org>) generate the typekits and copy them into your plain orocos
> project.
> Some more informations about Eigen and Rock/Orocos can be found here: (http://rock.opendfki.de/wiki/WikiStart/Toolchain/EigenTypes)
>
> But maybe there is a better solution out there.
there is also an eigen toolkit in itasc_core
http://git.mech.kuleuven.be/robotics/itasc_core.git
maybe we should put this somewhere else (separately)
any suggestions?
nick
>
> Alex
>
>>
>> JD
>> --
>> Orocos-Users mailing list
>> Orocos-Users [..] ... <mailto:Orocos-Users [..] ...>
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
> --
> Alexander Duda
> Ansgaritorswallstraße 21
> 28195 Bremen, Germany
>
> E-Mail: alexander [dot] duda [..] ... <mailto:alexander [dot] duda [..] ...>
>
>
>
eigen typekit
On Thu, Aug 9, 2012 at 3:28 AM, Dominick Vanthienen <
nick [dot] vanthienen [..] ...> wrote:
> maybe we should put this somewhere else (separately)
> any suggestions?
>
> nick
>
Maybe a separate repo just for various typekits?
-j
eigen typekit
Is there any reason why the Eigen typekit [1] in itasc shouldn't be moved over to the toolchain repo? If not/so where should it go to enable use outside of itasc or rock?
[1] http://git.mech.kuleuven.be/?p=robotics/itasc_core.git;a=tree;f=src;h=8ed00b081d57b3a3f879734b39f7996ec080c71c;hb=HEAD
eigen typekit
On 07/18/2013 04:44 AM, jonathan [dot] bohren [..] ... wrote:
> Is there any reason why the Eigen typekit [1] in itasc shouldn't be moved
> over to the toolchain repo? If not/so where should it go to enable ?
>
yes, I would like to get rid of it in itasc :)
I would suggest to give it, its own package, but under which stack/repo?
the kdl_typekit and rtt_tf are under rtt_geometry
can it go there?
suggestions from some devs?
> [1]
> http://git.mech.kuleuven.be/?p=robotics/itasc_core.git;a=tree;f=src;h=8e...
>
eigen typekit
On Thu, Jul 18, 2013 at 10:48 AM, Dominick Vanthienen <
dominick [dot] vanthienen [..] ...> wrote:
>
>
> On 07/18/2013 04:44 AM, jonathan [dot] bohren [..] ... wrote:
> > Is there any reason why the Eigen typekit [1] in itasc shouldn't be moved
> > over to the toolchain repo? If not/so where should it go to enable ?
> >
> yes, I would like to get rid of it in itasc :)
> I would suggest to give it, its own package, but under which stack/repo?
> the kdl_typekit and rtt_tf are under rtt_geometry
> can it go there?
>
+1
Ruben
suggestions from some devs?
>
> > [1]
> >
> http://git.mech.kuleuven.be/?p=robotics/itasc_core.git;a=tree;f=src;h=8e...
> >
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
eigen typekit
On 07/18/2013 11:58 AM, Ruben Smits wrote:
>
>
>
> On Thu, Jul 18, 2013 at 10:48 AM, Dominick Vanthienen
> <dominick [dot] vanthienen [..] ...
> <mailto:dominick [dot] vanthienen [..] ...>> wrote:
>
>
>
> On 07/18/2013 04:44 AM, jonathan [dot] bohren [..] ...
> <mailto:jonathan [dot] bohren [..] ...> wrote:
> > Is there any reason why the Eigen typekit [1] in itasc shouldn't
> be moved
> > over to the toolchain repo? If not/so where should it go to enable ?
> >
> yes, I would like to get rid of it in itasc :)
> I would suggest to give it, its own package, but under which
> stack/repo?
> the kdl_typekit and rtt_tf are under rtt_geometry
> can it go there?
>
>
>
++++
We (Rock) currently have to delete it when we want to run itasc ...
eigen typekit
On Thu, Jul 18, 2013 at 11:06 AM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:
> On 07/18/2013 11:58 AM, Ruben Smits wrote:
>
> On Thu, Jul 18, 2013 at 10:48 AM, Dominick Vanthienen <
> dominick [dot] vanthienen [..] ...> wrote:
>
>> On 07/18/2013 04:44 AM, jonathan [dot] bohren [..] ... wrote:
>> > Is there any reason why the Eigen typekit [1] in itasc shouldn't be
>> moved
>> > over to the toolchain repo? If not/so where should it go to enable ?
>> >
>> yes, I would like to get rid of it in itasc :)
>> I would suggest to give it, its own package, but under which stack/repo?
>> the kdl_typekit and rtt_tf are under rtt_geometry
>> can it go there?
>
> ++++
>
> We (Rock) currently have to delete it when we want to run itasc ...
>
For itasc and Rock, would it be better if eigen_typekit was in
rtt_geometry, or in it's own stand-alone package?
-j
eigen typekit
On 07/18/2013 05:10 PM, Jonathan Bohren wrote:sylvain [dot] joyeux [..] ...>> wrote:
>
>
> On Thu, Jul 18, 2013 at 11:06 AM, Sylvain Joyeux
> <sylvain [dot] joyeux [..] ...
>
> On 07/18/2013 11:58 AM, Ruben Smits wrote:
>> On Thu, Jul 18, 2013 at 10:48 AM, Dominick Vanthienen
>> <dominick [dot] vanthienen [..] ...
>> <mailto:dominick [dot] vanthienen [..] ...>> wrote:
>>
>> On 07/18/2013 04:44 AM, jonathan [dot] bohren [..] ...
>> <mailto:jonathan [dot] bohren [..] ...> wrote:
>> > Is there any reason why the Eigen typekit [1] in itasc
>> shouldn't be moved
>> > over to the toolchain repo? If not/so where should it go to
>> enable ?
>> >
>> yes, I would like to get rid of it in itasc :)
>> I would suggest to give it, its own package, but under which
>> stack/repo?
>> the kdl_typekit and rtt_tf are under rtt_geometry
>> can it go there?
>>
> ++++
>
> We (Rock) currently have to delete it when we want to run itasc ...
>
>
> For itasc and Rock, would it be better if eigen_typekit was in
> rtt_geometry, or in it's own stand-alone package?
In general, it would be good to split between what is ROS-related and
not. I see in rtt_geometry that kdl_lua is in there, which is obviously
ROS-independent ...
We don't need eigen_typekit, so we don't have a preference on where it
goes, though.
Just my two cents.
eigen typekit
Here's a PR with an eigen_typekit catkin package.
https://github.com/orocos-toolchain/rtt_geometry/pull/2
-j
On Thu, Jul 18, 2013 at 11:21 AM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:
> On 07/18/2013 05:10 PM, Jonathan Bohren wrote:
>
>
>
> On Thu, Jul 18, 2013 at 11:06 AM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:
>
>> On 07/18/2013 11:58 AM, Ruben Smits wrote:
>>
>> On Thu, Jul 18, 2013 at 10:48 AM, Dominick Vanthienen <
>> dominick [dot] vanthienen [..] ...> wrote:
>>
>>> On 07/18/2013 04:44 AM, jonathan [dot] bohren [..] ... wrote:
>>> > Is there any reason why the Eigen typekit [1] in itasc shouldn't be
>>> moved
>>> > over to the toolchain repo? If not/so where should it go to enable ?
>>> >
>>> yes, I would like to get rid of it in itasc :)
>>> I would suggest to give it, its own package, but under which stack/repo?
>>> the kdl_typekit and rtt_tf are under rtt_geometry
>>> can it go there?
>>
>> ++++
>>
>> We (Rock) currently have to delete it when we want to run itasc ...
>>
>
> For itasc and Rock, would it be better if eigen_typekit was in
> rtt_geometry, or in it's own stand-alone package?
>
> In general, it would be good to split between what is ROS-related and not.
> I see in rtt_geometry that kdl_lua is in there, which is obviously
> ROS-independent ...
>
> We don't need eigen_typekit, so we don't have a preference on where it
> goes, though.
>
> Just my two cents.
>
> --
> Sylvain Joyeux (Dr.Ing.)
> 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
> -----------------------------------------------------------------------
>
>
eigen typekit
On 07/19/2013 12:20 AM, Jonathan Bohren wrote:
> Here's a PR with an eigen_typekit catkin package.
> https://github.com/orocos-toolchain/rtt_geometry/pull/2
Quick question here: what is the rationale with using catkin ? (not
going to fight against it, since I don't need the package anyways. Just
wondering)
eigen typekit
It seems it is only used for the catkin_package macro. If we could do it
without this macro we should be fine.
Ruben
On Fri, Jul 19, 2013 at 9:10 AM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:
> On 07/19/2013 12:20 AM, Jonathan Bohren wrote:
> > Here's a PR with an eigen_typekit catkin package.
> > https://github.com/orocos-toolchain/rtt_geometry/pull/2
> Quick question here: what is the rationale with using catkin ? (not
> going to fight against it, since I don't need the package anyways. Just
> wondering)
>
> --
> Sylvain Joyeux (Dr.Ing.)
> 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
> -----------------------------------------------------------------------
>
>
eigen typekit
Since catkin is found just like any CMake module, you could also just do:
```
find_package(catkin)
if(catkin_FOUND)
# do catkin nonsense
endif()
```
It can also be made into a hybrid catkin-rosbuild package, but I'm planning
on creating another PR to migrate all of rtt_geometry to catkin.
Despite its issues, I like the greater flexibility that catkin offers. It's
still a little rough around the edges, but OSRF is continuously improving
it.
-j
On Fri, Jul 19, 2013 at 3:22 AM, Ruben Smits
<ruben [dot] smits [..] ...>wrote:
> It seems it is only used for the catkin_package macro. If we could do it
> without this macro we should be fine.
>
> Ruben
>
>
> On Fri, Jul 19, 2013 at 9:10 AM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:
>
>> On 07/19/2013 12:20 AM, Jonathan Bohren wrote:
>> > Here's a PR with an eigen_typekit catkin package.
>> > https://github.com/orocos-toolchain/rtt_geometry/pull/2
>> Quick question here: what is the rationale with using catkin ? (not
>> going to fight against it, since I don't need the package anyways. Just
>> wondering)
>>
>> --
>> Sylvain Joyeux (Dr.Ing.)
>> 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
>> -----------------------------------------------------------------------
>>
>>
>
>
> --
> Ruben Smits, Phd
> Chief Technology Officer
> Intermodalics BVBA
> +32479511786
> www.intermodalics.eu
>
eigen typekit
On 07/19/2013 09:32 AM, Jonathan Bohren wrote:
> Since catkin is found just like any CMake module, you could also just do:
>
> ```
> find_package(catkin)
> if(catkin_FOUND)
> # do catkin nonsense
> endif()
> ```
>
> It can also be made into a hybrid catkin-rosbuild package, but I'm
> planning on creating another PR to migrate all of rtt_geometry to catkin.
>
> Despite its issues, I like the greater flexibility that catkin offers.
> It's still a little rough around the edges, but OSRF is continuously
> improving it.
The point here is that RTT provides its own macros to build RTT-specific
packages. For the non-ros parts of rtt_geometry, that would be a better
pick than catkin.
Disclaimer: I personally dislike catkin with all my heart, it is again
something that tries to do way too much to be relied upon. The little
interaction I had with it while integrating the ROS transport in orogen
gave me the creeps.
eigen typekit
On Fri, Jul 19, 2013 at 4:28 AM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:
> The point here is that RTT provides its own macros to build RTT-specific
> packages. For the non-ros parts of rtt_geometry, that would be a better
> pick than catkin.
>
Well, the way I see it, catkin _is_ (or at least will be) the ROS part of
rtt_geometry. If the eigen typekit is going to be distributed with
orocos_toolchain, then sure, those package macros sound good. If it's going
to be distributed with the rtt_geometry packages, then it seems like we're
already in a ROS (catkin) environment, so using catkin makes sense.
If someone wants the eigen_typekit package to work differently, then they
are just as welcome as anyone to make a pull request.
> Disclaimer: I personally dislike catkin with all my heart, it is again
> something that tries to do way too much to be relied upon. The little
> interaction I had with it while integrating the ROS transport in orogen
> gave me the creeps.
>
Well you can see all my complaints about catkin in detail on the ROS
buildsystem SIG [1], and if you don't like how it's designed, please voice
your opinion!
For better or worse, catkin is taking over all of ROS from the bottom-up.
Even as of ROS groovy, the rosbuild compatibility mode has been made so
slow that I don't really consider it usable for large projects any more.
The fact of the matter is that the people at OSRF are the ones supporting
ROS development. They are developing catkin, and nearly all of the released
ROS packages now use the catkin buildsystem. Despite this push, however,
most people outside of OSRF and the Willow diaspora are still using
rosbuild.
Part of why I've been trying to use catkin in more projects (and different
types of projects) is because without these concrete test cases for
verdicts on catkin features, it's hard to argue about design decisions that
will (eventually) affect everyone using ROS. It would be terrible if catkin
was over-fit to the needs of the core ROS packages, and didn't support
integrating with Orocos, Rock, other robotics software toolchains, or even
ROS development patterns themselves.
-j
[1] https://groups.google.com/forum/#!forum/ros-sig-buildsystem
eigen typekit
hi,
I saw that the eigen typekit has moved to the rtt_geometry stack, as discussed on the orocos-users list months ago.
But for what releases is it supported?
Only for Orocos 2.7+?
And what about ROS versions? only Hydro? (I see it is in the Hydro-dev branch) or is it ROS independent?
I'm planning to delete it from itasc_core soon.
Nick
eigen typekit
On Thu, Dec 12, 2013 at 2:02 PM, Dominick Vanthienen <
dominick [dot] vanthienen [..] ...> wrote:
> I saw that the eigen typekit has moved to the rtt_geometry stack, as
> discussed on the orocos-users list months ago.
> But for what releases is it supported?
> Only for Orocos 2.7+?
> And what about ROS versions? only Hydro? (I see it is in the Hydro-dev
> branch) or is it ROS independent?
>
> I'm planning to delete it from itasc_core soon.
>
Currenlt eigen_typekit is definitely ros-independent (despite having a
`find_package(catkin REQUIRED)` in the CMakeLists.txt, but as you observed,
it's currently living in the rtt_geometry repository, which has a mixture
of ros-independent and ros-dependent things. We're in the final stages of
re-organizing and testing these things and I think rtt_geometry might need
to split up into twp repositories: one for the RTT/KDL interfaces, and one
for the RTT/TF interfaces.
-j
eigen typekit
On Thu, Jul 18, 2013 at 5:58 AM, Ruben Smits
<ruben [dot] smits [..] ...>wrote:
> On 07/18/2013 04:44 AM, jonathan [dot] bohren [..] ... wrote:
>> > Is there any reason why the Eigen typekit [1] in itasc shouldn't be
>> moved
>> > over to the toolchain repo? If not/so where should it go to enable ?
>> >
>> yes, I would like to get rid of it in itasc :)
>> I would suggest to give it, its own package, but under which stack/repo?
>> the kdl_typekit and rtt_tf are under rtt_geometry
>> can it go there?
>>
>
> +1
>
Should we put it in rtt_geometry, or should we create it's own repo on
github like stdint_typekit [2]? Maybe we should merge all these typekits
into a repo just for typekits?
[2] https://github.com/orocos-toolchain/stdint_typekit
-j
eigen typekit
On 07/18/2013 04:38 PM, Jonathan Bohren wrote:ruben [dot] smits [..] ...>> wrote:
>
> On Thu, Jul 18, 2013 at 5:58 AM, Ruben Smits <ruben [dot] smits [..] ...
>
> On 07/18/2013 04:44 AM, jonathan [dot] bohren [..] ... <mailto:jonathan [dot] bohren [..] ...> wrote:
> > Is there any reason why the Eigen typekit [1] in itasc shouldn't be moved
> > over to the toolchain repo? If not/so where should it go to enable ?
> >
> yes, I would like to get rid of it in itasc :)
> I would suggest to give it, its own package, but under which stack/repo?
> the kdl_typekit and rtt_tf are under rtt_geometry
> can it go there?
>
>
> +1
>
>
> Should we put it in rtt_geometry, or should we create it's own repo on github like stdint_typekit [2]? Maybe we should merge all these typekits into a repo just for typekits?
>
> [2] https://github.com/orocos-toolchain/stdint_typekit
>
> -j
it's own repo is always possible,
a big repo for all looks not so practical: you have to get all typekits even if you need only one
(and if the repo is a ros stack, people will try to compile them all, even if they don't have/need the dependencies...)
putting it in rtt_geometry looks fine, since kdl uses eigen under the hood anyway
(and lets admit, its a well maintained and frequently used repo, so the eigen typekit will profit from that :)