For those that don't -yet) know, it is very unrecommended to put Eigen
types on RTT dataflow, as well as types that have fields that are Eigen
types and std::vector of such types. The reason is that Eigen has, by
default, memory alignment requirements that are pretty hard to robustly
enforce in the RTT dataflow.
There actually is a workaround to this problem: Eigen fixed-size
matrices have a template parameter that allow to force the use of
non-aligned memory storage. The good news are that:
* for small types (think of the common Vector3d, Vector4d,
Quaternion), there is no performance impact (actually, non-aligned
storage is slightly quicker in our tests)
* the conversion between aligned and non-aligned types is automatic
Unfortunately, there is no way to enforce non-alignment on Quaternion
and Transform3d types. However, Quaterniond is OK -- as there are no
vectorized instructions (yet). Transform3d is to be left out.
If you are asking yourself "well, I already do it and it is fine", think
again. It can come and bite you anytime. It is just unlikely on 64bit
machines as allocators tend to align on 8 byte boundaries already. But
it happens.
Interested people can have a look at
http://gitorious.org/rock-base/types/blobs/master/base/eigen.h
to see how to specify the flag.
Some info on Eigen and Orocos
How about using -DEIGEN_DONT_ALIGN during compilation?
On Tue, Jan 11, 2011 at 18:08, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:
> For those that don't -yet) know, it is very unrecommended to put Eigen
> types on RTT dataflow, as well as types that have fields that are Eigen
> types and std::vector of such types. The reason is that Eigen has, by
> default, memory alignment requirements that are pretty hard to robustly
> enforce in the RTT dataflow.
>
> There actually is a workaround to this problem: Eigen fixed-size
> matrices have a template parameter that allow to force the use of
> non-aligned memory storage. The good news are that:
> * for small types (think of the common Vector3d, Vector4d,
> Quaternion), there is no performance impact (actually, non-aligned
> storage is slightly quicker in our tests)
> * the conversion between aligned and non-aligned types is automatic
>
> Unfortunately, there is no way to enforce non-alignment on Quaternion
> and Transform3d types. However, Quaterniond is OK -- as there are no
> vectorized instructions (yet). Transform3d is to be left out.
>
> If you are asking yourself "well, I already do it and it is fine", think
> again. It can come and bite you anytime. It is just unlikely on 64bit
> machines as allocators tend to align on 8 byte boundaries already. But
> it happens.
>
> Interested people can have a look at
>
> http://gitorious.org/rock-base/types/blobs/master/base/eigen.h
>
> to see how to specify the flag.
> --
> Sylvain Joyeux (Dr.Ing.)
> Space & Security 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
> -----------------------------------------------------------------------
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
Some info on Eigen and Orocos
On Wed, Jan 12, 2011 at 10:14 AM, Piotr Trojanek
<piotr [dot] trojanek [..] ...>wrote:
> How about using -DEIGEN_DONT_ALIGN during compilation?
Although -DEIGEN_DONT_ALIGN will do the trick, it may be overkill since it
affects all your Eigen data structures. Unaligned data is only required for
the dataflow-relevant structures. You probably want to preserve aligned data
for performing (vectorized) computations elsewhere in your code.
0.02€
Adolfo.
>
> On Tue, Jan 11, 2011 at 18:08, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:
>
>> For those that don't -yet) know, it is very unrecommended to put Eigen
>> types on RTT dataflow, as well as types that have fields that are Eigen
>> types and std::vector of such types. The reason is that Eigen has, by
>> default, memory alignment requirements that are pretty hard to robustly
>> enforce in the RTT dataflow.
>>
>> There actually is a workaround to this problem: Eigen fixed-size
>> matrices have a template parameter that allow to force the use of
>> non-aligned memory storage. The good news are that:
>> * for small types (think of the common Vector3d, Vector4d,
>> Quaternion), there is no performance impact (actually, non-aligned
>> storage is slightly quicker in our tests)
>> * the conversion between aligned and non-aligned types is automatic
>>
>> Unfortunately, there is no way to enforce non-alignment on Quaternion
>> and Transform3d types. However, Quaterniond is OK -- as there are no
>> vectorized instructions (yet). Transform3d is to be left out.
>>
>> If you are asking yourself "well, I already do it and it is fine", think
>> again. It can come and bite you anytime. It is just unlikely on 64bit
>> machines as allocators tend to align on 8 byte boundaries already. But
>> it happens.
>>
>> Interested people can have a look at
>>
>> http://gitorious.org/rock-base/types/blobs/master/base/eigen.h
>>
>> to see how to specify the flag.
>> --
>> Sylvain Joyeux (Dr.Ing.)
>> Space & Security 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
>> -----------------------------------------------------------------------
>> --
>> Orocos-Users mailing list
>> Orocos-Users [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>
>
>
>
> --
> Piotr Trojanek
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>
Some info on Eigen and Orocos
On 01/12/2011 01:12 PM, Adolfo Rodríguez Tsouroukdissian wrote:piotr [dot] trojanek [..] ...>> wrote:
>
>
> On Wed, Jan 12, 2011 at 10:14 AM, Piotr Trojanek
> <piotr [dot] trojanek [..] ...
>
> How about using -DEIGEN_DONT_ALIGN during compilation?
>
>
> Although -DEIGEN_DONT_ALIGN will do the trick, it may be overkill since
> it affects all your Eigen data structures. Unaligned data is only
> required for the dataflow-relevant structures. You probably want to
> preserve aligned data for performing (vectorized) computations elsewhere
> in your code.
>
> 0.02€
Moreover, as soon as you start using -DEIGEN_DONT_ALIGN (I think that's
the right definition, but anyway), you have to be *really* sure that all
libraries you are using are also compiled with that flag. Hardly robust
in my opinion
Some info on Eigen and Orocos
A Dijous, 13 de gener de 2011, Sylvain Joyeux va escriure:piotr [dot] trojanek [..] ...>> wrote:
> On 01/12/2011 01:12 PM, Adolfo Rodríguez Tsouroukdissian wrote:
> > On Wed, Jan 12, 2011 at 10:14 AM, Piotr Trojanek
> >
> > <piotr [dot] trojanek [..] ...
> > How about using -DEIGEN_DONT_ALIGN during compilation?
> >
> > Although -DEIGEN_DONT_ALIGN will do the trick, it may be overkill since
> > it affects all your Eigen data structures. Unaligned data is only
> > required for the dataflow-relevant structures. You probably want to
> > preserve aligned data for performing (vectorized) computations elsewhere
> > in your code.
> >
> > 0.02€
>
> Moreover, as soon as you start using -DEIGEN_DONT_ALIGN (I think that's
> the right definition, but anyway), you have to be *really* sure that all
> libraries you are using are also compiled with that flag. Hardly robust
> in my opinion
please, could you explain this? because, AFAIK Eigen is a pure template
library defined in the headers. So, if you use that define in a component, you
obj would be affected by that. But, I don't know if this will be affect in the
process to link against another library (eg. RTT).
Regards,
Leo
Some info on Eigen and Orocos
On 01/13/2011 11:07 AM, Leopold Palomo-Avellaneda wrote:
>> Moreover, as soon as you start using -DEIGEN_DONT_ALIGN (I think that's
>> the right definition, but anyway), you have to be *really* sure that all
>> libraries you are using are also compiled with that flag. Hardly robust
>> in my opinion
>
> please, could you explain this? because, AFAIK Eigen is a pure template
> library defined in the headers. So, if you use that define in a component, you
> obj would be affected by that. But, I don't know if this will be affect in the
> process to link against another library (eg. RTT).
Well. Let's assume you have two libraries, A and B. A is compiled with
DONT_ALIGN, B is not.
A creates an Eigen::Vector3d -- which is therefore not aligned -- and
passes it to B. Unfortunately, B requires its Eigen data structures to
be aligned. Boom.
Some info on Eigen and Orocos
2011/1/13 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> On 01/13/2011 11:07 AM, Leopold Palomo-Avellaneda wrote:
> >> Moreover, as soon as you start using -DEIGEN_DONT_ALIGN (I think that's
> >> the right definition, but anyway), you have to be *really* sure that all
> >> libraries you are using are also compiled with that flag. Hardly robust
> >> in my opinion
> >
> > please, could you explain this? because, AFAIK Eigen is a pure template
> > library defined in the headers. So, if you use that define in a
> component, you
> > obj would be affected by that. But, I don't know if this will be affect
> in the
> > process to link against another library (eg. RTT).
> Well. Let's assume you have two libraries, A and B. A is compiled with
> DONT_ALIGN, B is not.
>
> A creates an Eigen::Vector3d -- which is therefore not aligned -- and
> passes it to B. Unfortunately, B requires its Eigen data structures to
> be aligned. Boom.
>
>
Eigen isn't able to _recognized_ the non-aligned type and make the cast like
it does when you use the template parameter DontAlign ?
Philippe
Some info on Eigen and Orocos
On 01/13/2011 02:23 PM, Philippe Hamelin wrote:
> A creates an Eigen::Vector3d -- which is therefore not aligned -- and
> passes it to B. Unfortunately, B requires its Eigen data structures to
> be aligned. Boom.
>
>
> Eigen isn't able to _recognized_ the non-aligned type and make the cast
> like it does when you use the template parameter DontAlign ?
From what I saw, DONT_ALIGN really turns off alignment, it does not
change the default template parameter in Matrix. I guess this is
because, for some types, alignment cannot be turned off.
Take this with a grain of salt: it was a quick analysis we did on Eigen2
and we might have been wrong. Anyway, our experience in rock is that
having a separate type for "dataflow-friendly" types is a good option.
Especially tied with orogen, since orogen will generate an error if you
use the regular types on the dataflow (since it does not know about
them), while the non-align types pass fine.
Some info on Eigen and Orocos
On 01/13/2011 02:30 PM, Sylvain Joyeux wrote:
> On 01/13/2011 02:23 PM, Philippe Hamelin wrote:
>> A creates an Eigen::Vector3d -- which is therefore not aligned -- and
>> passes it to B. Unfortunately, B requires its Eigen data structures to
>> be aligned. Boom.
>>
>>
>> Eigen isn't able to _recognized_ the non-aligned type and make the cast
>> like it does when you use the template parameter DontAlign ?
> From what I saw, DONT_ALIGN really turns off alignment, it does not
> change the default template parameter in Matrix. I guess this is
> because, for some types, alignment cannot be turned off.
Precision: cannot be turned off through template parameters
> Take this with a grain of salt: it was a quick analysis we did on Eigen2
> and we might be wrong. Anyway, our experience in rock is that
> having a separate type for "dataflow-friendly" types is a good option.
for "dataflow-friendly" Eigen types.
> Especially tied with orogen, since orogen will generate an error if you
> use the regular types on the dataflow (since it does not know about
> them), while the non-align types pass fine.
Some info on Eigen and Orocos
A Dijous, 13 de gener de 2011, Sylvain Joyeux va escriure:
> On 01/13/2011 02:30 PM, Sylvain Joyeux wrote:
> > On 01/13/2011 02:23 PM, Philippe Hamelin wrote:
> >> A creates an Eigen::Vector3d -- which is therefore not aligned --
> >> and passes it to B. Unfortunately, B requires its Eigen data
> >> structures to be aligned. Boom.
> >>
> >> Eigen isn't able to _recognized_ the non-aligned type and make the cast
> >> like it does when you use the template parameter DontAlign ?
> >>
> > From what I saw, DONT_ALIGN really turns off alignment, it does not
> >
> > change the default template parameter in Matrix. I guess this is
> > because, for some types, alignment cannot be turned off.
>
> Precision: cannot be turned off through template parameters
>
> > Take this with a grain of salt: it was a quick analysis we did on Eigen2
> > and we might be wrong. Anyway, our experience in rock is that
> > having a separate type for "dataflow-friendly" types is a good option.
>
> for "dataflow-friendly" Eigen types.
>
> > Especially tied with orogen, since orogen will generate an error if you
> > use the regular types on the dataflow (since it does not know about
> > them), while the non-align types pass fine.
pler, help me clarifying one thing that I don't understand. For example, we
have two components. One component use eigen to calculate something, and
publish/send using a port of this type.
The other component connects to that port, because needs this type. The two
components are separated in compilation and link. Both uses, or corba or
mqueue or ros messages or whatever media provided by rtt to the communication
(we use components, no?) to send or receive data. This data, must be
serialized and deserialized to be send between components.
So, you are talking that in this step, typekit o whatever that uses RTT fails
when you send/receive data using eigen structures?
Regards,
Leo
Some info on Eigen and Orocos
On 01/13/2011 04:55 PM, Leopold Palomo-Avellaneda wrote:
> A Dijous, 13 de gener de 2011, Sylvain Joyeux va escriure:
>> On 01/13/2011 02:30 PM, Sylvain Joyeux wrote:
>>> On 01/13/2011 02:23 PM, Philippe Hamelin wrote:
>>>> A creates an Eigen::Vector3d -- which is therefore not aligned --
>>>> and passes it to B. Unfortunately, B requires its Eigen data
>>>> structures to be aligned. Boom.
>>>>
>>>> Eigen isn't able to _recognized_ the non-aligned type and make the cast
>>>> like it does when you use the template parameter DontAlign ?
>>>>
>>> From what I saw, DONT_ALIGN really turns off alignment, it does not
>>>
>>> change the default template parameter in Matrix. I guess this is
>>> because, for some types, alignment cannot be turned off.
>>
>> Precision: cannot be turned off through template parameters
>>
>>> Take this with a grain of salt: it was a quick analysis we did on Eigen2
>>> and we might be wrong. Anyway, our experience in rock is that
>>> having a separate type for "dataflow-friendly" types is a good option.
>>
>> for "dataflow-friendly" Eigen types.
>>
>>> Especially tied with orogen, since orogen will generate an error if you
>>> use the regular types on the dataflow (since it does not know about
>>> them), while the non-align types pass fine.
>
> pler, help me clarifying one thing that I don't understand. For example, we
> have two components. One component use eigen to calculate something, and
> publish/send using a port of this type.
>
> The other component connects to that port, because needs this type. The two
> components are separated in compilation and link. Both uses, or corba or
> mqueue or ros messages or whatever media provided by rtt to the communication
> (we use components, no?) to send or receive data. This data, must be
> serialized and deserialized to be send between components.
I don't "just use components". I write nice C++ libraries that get
integrated into Orocos components. That way, I am sure that I won't hit
a wall when the next "big integration framework" comes in.
> So, you are talking that in this step, typekit o whatever that uses RTT fails
> when you send/receive data using eigen structures?
There are multiple "parts" where this alignment thing kicks in:
1. shared library boundaries
2. component boundaries (properties, dataflow)
What I was discussing about DONT_ALIGN is 1. If you have two shared
libraries, one with DONT_ALIGN, one without, then passing eigen-enabled
types between these libraries is dangerous.
About 2. 2. is actually not so much about the transports, but about the
dataflow. Indeed, the dataflow *needs* to store (copy) the data samples
you send, and is therefore subject to alignment constraints. So, again,
you need all the libraries defining your task contexts to be compiled
with DONT_ALIGN. And, in effect, all the libraries that are used in the
libraries that define your task contexts (try saying that 10 times fast !).
In effect, the only way to be *really* sure that nothing will go wrong
is to compile *everything* with DONT_ALIGN. Not really a nice situation.
Some info on Eigen and Orocos
On Friday 14 January 2011 09:57:41 Sylvain Joyeux wrote:
> On 01/13/2011 04:55 PM, Leopold Palomo-Avellaneda wrote:
> > A Dijous, 13 de gener de 2011, Sylvain Joyeux va escriure:
> >> On 01/13/2011 02:30 PM, Sylvain Joyeux wrote:
> >>> On 01/13/2011 02:23 PM, Philippe Hamelin wrote:
> >>>> A creates an Eigen::Vector3d -- which is therefore not aligned
> >>>> -- and passes it to B. Unfortunately, B requires its Eigen data
> >>>> structures to be aligned. Boom.
> >>>>
> >>>> Eigen isn't able to _recognized_ the non-aligned type and make the
> >>>> cast like it does when you use the template parameter DontAlign ?
> >>>>
> >>> From what I saw, DONT_ALIGN really turns off alignment, it does
> >>> not
> >>>
> >>> change the default template parameter in Matrix. I guess this is
> >>> because, for some types, alignment cannot be turned off.
> >>
> >> Precision: cannot be turned off through template parameters
> >>
> >>> Take this with a grain of salt: it was a quick analysis we did on
> >>> Eigen2 and we might be wrong. Anyway, our experience in rock is that
> >>> having a separate type for "dataflow-friendly" types is a good option.
> >>
> >> for "dataflow-friendly" Eigen types.
> >>
> >>> Especially tied with orogen, since orogen will generate an error if you
> >>> use the regular types on the dataflow (since it does not know about
> >>> them), while the non-align types pass fine.
> >
> > pler, help me clarifying one thing that I don't understand. For example,
> > we have two components. One component use eigen to calculate something,
> > and publish/send using a port of this type.
> >
> > The other component connects to that port, because needs this type. The
> > two components are separated in compilation and link. Both uses, or
> > corba or mqueue or ros messages or whatever media provided by rtt to the
> > communication (we use components, no?) to send or receive data. This
> > data, must be serialized and deserialized to be send between components.
>
> I don't "just use components". I write nice C++ libraries that get
> integrated into Orocos components. That way, I am sure that I won't hit
> a wall when the next "big integration framework" comes in.
>
> > So, you are talking that in this step, typekit o whatever that uses RTT
> > fails when you send/receive data using eigen structures?
>
> There are multiple "parts" where this alignment thing kicks in:
> 1. shared library boundaries
> 2. component boundaries (properties, dataflow)
>
> What I was discussing about DONT_ALIGN is 1. If you have two shared
> libraries, one with DONT_ALIGN, one without, then passing eigen-enabled
> types between these libraries is dangerous.
>
> About 2. 2. is actually not so much about the transports, but about the
> dataflow. Indeed, the dataflow *needs* to store (copy) the data samples
> you send, and is therefore subject to alignment constraints. So, again,
> you need all the libraries defining your task contexts to be compiled
> with DONT_ALIGN. And, in effect, all the libraries that are used in the
> libraries that define your task contexts (try saying that 10 times fast !).
>
> In effect, the only way to be *really* sure that nothing will go wrong
> is to compile *everything* with DONT_ALIGN. Not really a nice situation.
I have no experience with alignment tricks, but as long as we use the copy
constructor of the eigen types, and we use the new() operator to allocate
every instance in the data-flow code, shouldn't everything be fine then ?
I'd prefer to fix the dataflow code rather than to work around it.
Peter
Some info on Eigen and Orocos
On 01/14/2011 10:40 AM, Peter Soetens wrote:
> I have no experience with alignment tricks, but as long as we use the copy
> constructor of the eigen types, and we use the new() operator to allocate
> every instance in the data-flow code, shouldn't everything be fine then ?
Nope. The issue is that *any* type that is either an eigen type of size
a multiple of 16 or contains an eigen type whose size is a multiple of
16 needs to be aligned on 16 bytes boundaries. This includes
std::vector. Which is used for buffers.
Eigen has tricks to make std::vector align on 16bytes boundaries, but it
involves passing a custom allocator.
> I'd prefer to fix the dataflow code rather than to work around it.
For god sake, do *not* touch the dafaflow to please eigen. RTT is
complex (and templated) enough as it is, and this is both a very special
case and an issue that need IMO to be resolved in Eigen itself. These
alignment requirements are very constraining, even in "normal" shared
library code.
Some info on Eigen and Orocos
On Friday 14 January 2011 10:52:22 Sylvain Joyeux wrote:
> On 01/14/2011 10:40 AM, Peter Soetens wrote:
> > I have no experience with alignment tricks, but as long as we use the
> > copy constructor of the eigen types, and we use the new() operator to
> > allocate every instance in the data-flow code, shouldn't everything be
> > fine then ?
>
> Nope. The issue is that *any* type that is either an eigen type of size
> a multiple of 16 or contains an eigen type whose size is a multiple of
> 16 needs to be aligned on 16 bytes boundaries. This includes
> std::vector. Which is used for buffers.
128bit boundaries ? Wow.
>
> Eigen has tricks to make std::vector align on 16bytes boundaries, but it
> involves passing a custom allocator.
>
> > I'd prefer to fix the dataflow code rather than to work around it.
>
> For god sake, do *not* touch the dafaflow to please eigen. RTT is
> complex (and templated) enough as it is, and this is both a very special
> case and an issue that need IMO to be resolved in Eigen itself. These
> alignment requirements are very constraining, even in "normal" shared
> library code.
So the constraints for RTT types become then
- default constructible
- copy constructor
- no alignment requirements
Less work for me. Fair enough.
Peter
Some info on Eigen and Orocos
On 01/14/2011 11:01 AM, Peter Soetens wrote:
> On Friday 14 January 2011 10:52:22 Sylvain Joyeux wrote:
>> On 01/14/2011 10:40 AM, Peter Soetens wrote:
>>> I have no experience with alignment tricks, but as long as we use the
>>> copy constructor of the eigen types, and we use the new() operator to
>>> allocate every instance in the data-flow code, shouldn't everything be
>>> fine then ?
>> Nope. The issue is that *any* type that is either an eigen type of size
>> a multiple of 16 or contains an eigen type whose size is a multiple of
>> 16 needs to be aligned on 16 bytes boundaries. This includes
>> std::vector. Which is used for buffers.
> 128bit boundaries ? Wow.
>
>> Eigen has tricks to make std::vector align on 16bytes boundaries, but it
>> involves passing a custom allocator.
>>
>>> I'd prefer to fix the dataflow code rather than to work around it.
>> For god sake, do *not* touch the dafaflow to please eigen. RTT is
>> complex (and templated) enough as it is, and this is both a very special
>> case and an issue that need IMO to be resolved in Eigen itself. These
>> alignment requirements are very constraining, even in "normal" shared
>> library code.
> So the constraints for RTT types become then
> - default constructible
> - copy constructor
> - no alignment requirements
>
> Less work for me. Fair enough.
>
> Peter
Dear all,
I have a problem that is related to this discussion: I get a Segfault
from time to time (see below) What can I do to prevent it?
At the moment, I just recompile my code and most of the time it works
again, sometimes recompiling more components that are involved does the
trick, I don't know why, because nothing changed...
3.881 [ Info ][FixedObject] Thread created with scheduler type '0',
priority 0 and period 0.
3.881 [ Info ][DeploymentComponent::loadComponent] Adding FixedObject
as new peer: OK.
3.881 [ Warning][DeploymentComponent::loadComponents] Lowering scheduler
type to SCHED_OTHER for non-privileged users..
3.881 [ Info ][DeploymentComponent::loadComponents] Added component
FixedObject to group 0
3.882 [ Info ][Thread] Creating Thread for scheduler: 0
[New Thread 0xaf693b70 (LWP 3780)]
3.882 [ Info ][CartesianMotion] Thread created with scheduler type
'0', priority 0 and period 0.
deployer-gnulinux:
/home/u0065688/src/svn/robotics-ros/packages/cturtle_stacks/geometry/eigen/include/Eigen/src/Core/MatrixStorage.h:44:
Eigen::ei_matrix_array<T, Size, MatrixOptions, Align>::ei_matrix_array()
[with T = double, int Size = 36, int MatrixOptions = 2, bool Align =
true]: Assertion `(reinterpret_cast<size_t>(array) & 0xf) == 0 && "this
assertion is explained here:
http://eigen.tuxfamily.org/dox/UnalignedArrayAssert.html **** READ THIS
WEB PAGE !!! ****"' failed.
Program received signal SIGABRT, Aborted.
0xb7fe1424 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7fe1424 in __kernel_vsyscall ()
#1 0xb7861941 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0xb7864e42 in abort () at abort.c:92
#3 0xb785a8e8 in __assert_fail (
assertion=0xb309e2cc "(reinterpret_cast<size_t>(array) & 0xf) == 0
&& \"this assertion is explained here:
http://eigen.tuxfamily.org/dox/UnalignedArrayAssert.html **** READ THIS
WEB PAGE !!! ****\"", file=0xb309e258
"/home/u0065688/src/svn/robotics-ros/packages/cturtle_stacks/geometry/eigen/include/Eigen/src/Core/MatrixStorage.h",
line=44,
function=0xb30a8800 "Eigen::ei_matrix_array<T, Size, MatrixOptions,
Align>::ei_matrix_array() [with T = double, int Size = 36, int
MatrixOptions = 2, bool Align = true]") at assert.c:81
#4 0xb2fec07b in ei_matrix_array (this=<value optimized out>, name=...)
at
/home/u0065688/src/svn/robotics-ros/packages/cturtle_stacks/geometry/eigen/include/Eigen/src/Core/MatrixStorage.h:43
#5 ei_matrix_storage (this=<value optimized out>, name=...)
at
/home/u0065688/src/svn/robotics-ros/packages/cturtle_stacks/geometry/eigen/include/Eigen/src/Core/MatrixStorage.h:76
#6 Matrix (this=<value optimized out>, name=...) at
/home/u0065688/src/svn/robotics-ros/packages/cturtle_stacks/geometry/eigen/include/Eigen/src/Core/Matrix.h:309
#7 iTaSC::CartesianMotion::CartesianMotion (this=<value optimized out>,
name=...)
at
/home/u0065688/src/svn/robotics-ros/packages/private-kul-ros-pkg/iTaSC/src/CartesianMotion.cpp:49
#8 0xb2fec2c4 in createComponent (instance_name=...) at
/home/u0065688/src/svn/robotics-ros/packages/private-kul-ros-pkg/iTaSC/src/CartesianMotion.cpp:29
#9 0xb7d65d9a in OCL::ComponentLoader::loadComponent (this=0x8076ac8,
name=..., type=...)
at
/home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/ocl/deployment/ComponentLoader.cpp:495
#10 0xb7cd25c8 in OCL::DeploymentComponent::loadComponent
(this=0xbfffea50, name=..., type=...)
at
/home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/ocl/deployment/DeploymentComponent.cpp:1491
#11 0xb7cd9d09 in OCL::DeploymentComponent::loadComponentsInGroup
(this=0xbfffea50, configurationfile=..., group=0)
at
/home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/ocl/deployment/DeploymentComponent.cpp:770
#12 0xb7cdbc8f in OCL::DeploymentComponent::kickStart (this=0xbfffea50,
configurationfile=...)
at
/home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/ocl/deployment/DeploymentComponent.cpp:490
#13 0x08052868 in main (argc=<value optimized out>, argv=0xbfffec74) at
/home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/ocl/bin/deployer.cpp:150
line 29 of CartesianMotion.cpp states:
ORO_CREATE_COMPONENT( iTaSC::CartesianMotion );
line 49 is the last line of the following:
CartesianMotion::CartesianMotion(const std::string& name) :
SubTask(name, PreOperational),
Kp_prop(VectorXd::Zero(6)),
use_pose(true),
rotation_type(RPY),
rotation_ref(true),
Wy_prop(std::vector<double>(6, 1.0)),
ydot(6),
Kp(VectorXd::Zero(6)),
yd(VectorXd::Zero(6)),
dyd(VectorXd::Zero(6)),
ym(VectorXd::Zero(6)),
Jf_kdl(6)
{...
Nick
Some info on Eigen and Orocos
Have you tried this solution?
http://eigen.tuxfamily.org/dox/StructHavingEigenMembers.html#how
On Mon, Jan 17, 2011 at 14:29, Dominick Vanthienen <
dominick [dot] vanthienen [..] ...> wrote:
>
>
>
>
> On 01/14/2011 11:01 AM, Peter Soetens wrote:
> > On Friday 14 January 2011 10:52:22 Sylvain Joyeux wrote:
> >> On 01/14/2011 10:40 AM, Peter Soetens wrote:
> >>> I have no experience with alignment tricks, but as long as we use the
> >>> copy constructor of the eigen types, and we use the new() operator to
> >>> allocate every instance in the data-flow code, shouldn't everything be
> >>> fine then ?
> >> Nope. The issue is that *any* type that is either an eigen type of size
> >> a multiple of 16 or contains an eigen type whose size is a multiple of
> >> 16 needs to be aligned on 16 bytes boundaries. This includes
> >> std::vector. Which is used for buffers.
> > 128bit boundaries ? Wow.
> >
> >> Eigen has tricks to make std::vector align on 16bytes boundaries, but it
> >> involves passing a custom allocator.
> >>
> >>> I'd prefer to fix the dataflow code rather than to work around it.
> >> For god sake, do *not* touch the dafaflow to please eigen. RTT is
> >> complex (and templated) enough as it is, and this is both a very special
> >> case and an issue that need IMO to be resolved in Eigen itself. These
> >> alignment requirements are very constraining, even in "normal" shared
> >> library code.
> > So the constraints for RTT types become then
> > - default constructible
> > - copy constructor
> > - no alignment requirements
> >
> > Less work for me. Fair enough.
> >
> > Peter
> Dear all,
>
> I have a problem that is related to this discussion: I get a Segfault
> from time to time (see below) What can I do to prevent it?
> At the moment, I just recompile my code and most of the time it works
> again, sometimes recompiling more components that are involved does the
> trick, I don't know why, because nothing changed...
>
> 3.881 [ Info ][FixedObject] Thread created with scheduler type '0',
> priority 0 and period 0.
> 3.881 [ Info ][DeploymentComponent::loadComponent] Adding FixedObject
> as new peer: OK.
> 3.881 [ Warning][DeploymentComponent::loadComponents] Lowering scheduler
> type to SCHED_OTHER for non-privileged users..
> 3.881 [ Info ][DeploymentComponent::loadComponents] Added component
> FixedObject to group 0
> 3.882 [ Info ][Thread] Creating Thread for scheduler: 0
> [New Thread 0xaf693b70 (LWP 3780)]
> 3.882 [ Info ][CartesianMotion] Thread created with scheduler type
> '0', priority 0 and period 0.
> deployer-gnulinux:
>
> /home/u0065688/src/svn/robotics-ros/packages/cturtle_stacks/geometry/eigen/include/Eigen/src/Core/MatrixStorage.h:44:
> Eigen::ei_matrix_array<T, Size, MatrixOptions, Align>::ei_matrix_array()
> [with T = double, int Size = 36, int MatrixOptions = 2, bool Align =
> true]: Assertion `(reinterpret_cast<size_t>(array) & 0xf) == 0 && "this
> assertion is explained here:
> http://eigen.tuxfamily.org/dox/UnalignedArrayAssert.html **** READ THIS
> WEB PAGE !!! ****"' failed.
>
> Program received signal SIGABRT, Aborted.
> 0xb7fe1424 in __kernel_vsyscall ()
> (gdb) bt
> #0 0xb7fe1424 in __kernel_vsyscall ()
> #1 0xb7861941 in raise (sig=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #2 0xb7864e42 in abort () at abort.c:92
> #3 0xb785a8e8 in __assert_fail (
> assertion=0xb309e2cc "(reinterpret_cast<size_t>(array) & 0xf) == 0
> && \"this assertion is explained here:
> http://eigen.tuxfamily.org/dox/UnalignedArrayAssert.html **** READ THIS
> WEB PAGE !!! ****\"", file=0xb309e258
>
> "/home/u0065688/src/svn/robotics-ros/packages/cturtle_stacks/geometry/eigen/include/Eigen/src/Core/MatrixStorage.h",
>
> line=44,
> function=0xb30a8800 "Eigen::ei_matrix_array<T, Size, MatrixOptions,
> Align>::ei_matrix_array() [with T = double, int Size = 36, int
> MatrixOptions = 2, bool Align = true]") at assert.c:81
> #4 0xb2fec07b in ei_matrix_array (this=<value optimized out>, name=...)
> at
>
> /home/u0065688/src/svn/robotics-ros/packages/cturtle_stacks/geometry/eigen/include/Eigen/src/Core/MatrixStorage.h:43
> #5 ei_matrix_storage (this=<value optimized out>, name=...)
> at
>
> /home/u0065688/src/svn/robotics-ros/packages/cturtle_stacks/geometry/eigen/include/Eigen/src/Core/MatrixStorage.h:76
> #6 Matrix (this=<value optimized out>, name=...) at
>
> /home/u0065688/src/svn/robotics-ros/packages/cturtle_stacks/geometry/eigen/include/Eigen/src/Core/Matrix.h:309
> #7 iTaSC::CartesianMotion::CartesianMotion (this=<value optimized out>,
> name=...)
> at
>
> /home/u0065688/src/svn/robotics-ros/packages/private-kul-ros-pkg/iTaSC/src/CartesianMotion.cpp:49
> #8 0xb2fec2c4 in createComponent (instance_name=...) at
>
> /home/u0065688/src/svn/robotics-ros/packages/private-kul-ros-pkg/iTaSC/src/CartesianMotion.cpp:29
> #9 0xb7d65d9a in OCL::ComponentLoader::loadComponent (this=0x8076ac8,
> name=..., type=...)
> at
>
> /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/ocl/deployment/ComponentLoader.cpp:495
> #10 0xb7cd25c8 in OCL::DeploymentComponent::loadComponent
> (this=0xbfffea50, name=..., type=...)
> at
>
> /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/ocl/deployment/DeploymentComponent.cpp:1491
> #11 0xb7cd9d09 in OCL::DeploymentComponent::loadComponentsInGroup
> (this=0xbfffea50, configurationfile=..., group=0)
> at
>
> /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/ocl/deployment/DeploymentComponent.cpp:770
> #12 0xb7cdbc8f in OCL::DeploymentComponent::kickStart (this=0xbfffea50,
> configurationfile=...)
> at
>
> /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/ocl/deployment/DeploymentComponent.cpp:490
> #13 0x08052868 in main (argc=<value optimized out>, argv=0xbfffec74) at
>
> /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/ocl/bin/deployer.cpp:150
>
>
> line 29 of CartesianMotion.cpp states:
> ORO_CREATE_COMPONENT( iTaSC::CartesianMotion );
>
> line 49 is the last line of the following:
>
> CartesianMotion::CartesianMotion(const std::string& name) :
> SubTask(name, PreOperational),
> Kp_prop(VectorXd::Zero(6)),
> use_pose(true),
> rotation_type(RPY),
> rotation_ref(true),
> Wy_prop(std::vector<double>(6, 1.0)),
> ydot(6),
> Kp(VectorXd::Zero(6)),
> yd(VectorXd::Zero(6)),
> dyd(VectorXd::Zero(6)),
> ym(VectorXd::Zero(6)),
> Jf_kdl(6)
> {...
>
> Nick
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
Some info on Eigen and Orocos
On 01/18/2011 10:36 AM, Piotr Trojanek wrote:
> Have you tried this solution? http://eigen.tuxfamily.org/dox/StructHavingEigenMembers.html#how
Thank you!
This works (so far...)
FYI: what I tried
I first read the wiki of eigen and this thread: it always concerned
eigen types of FIXED size, but I use VectorXd, MatrixXd of a non-fixed
type, hence my posted problem.
I tried to put the "Dontalign" option in the initialization of my
vectors, comparable with what was proposed in the typedef in
http://gitorious.org/rock-base/types/blobs/master/base/eigen.h
but this didn't work either in my case.
> On Mon, Jan 17, 2011 at 14:29, Dominick Vanthienen<dominick [dot] vanthienen [..] ...dominick [dot] vanthienen [..] ...>> wrote:
>
>
>
>
> On 01/14/2011 11:01 AM, Peter Soetens wrote:
>> On Friday 14 January 2011 10:52:22 Sylvain Joyeux wrote:
>>> On 01/14/2011 10:40 AM, Peter Soetens wrote:
>>>> I have no experience with alignment tricks, but as long as we use the
>>>> copy constructor of the eigen types, and we use the new() operator to
>>>> allocate every instance in the data-flow code, shouldn't everything be
>>>> fine then ?
>>> Nope. The issue is that *any* type that is either an eigen type of size
>>> a multiple of 16 or contains an eigen type whose size is a multiple of
>>> 16 needs to be aligned on 16 bytes boundaries. This includes
>>> std::vector. Which is used for buffers.
>> 128bit boundaries ? Wow.
>>
>>> Eigen has tricks to make std::vector align on 16bytes boundaries, but it
>>> involves passing a custom allocator.
>>>
>>>> I'd prefer to fix the dataflow code rather than to work around it.
>>> For god sake, do *not* touch the dafaflow to please eigen. RTT is
>>> complex (and templated) enough as it is, and this is both a very special
>>> case and an issue that need IMO to be resolved in Eigen itself. These
>>> alignment requirements are very constraining, even in "normal" shared
>>> library code.
>> So the constraints for RTT types become then
>> - default constructible
>> - copy constructor
>> - no alignment requirements
>>
>> Less work for me. Fair enough.
>>
>> Peter
> Dear all,
>
> I have a problem that is related to this discussion: I get a Segfault
> from time to time (see below) What can I do to prevent it?
> At the moment, I just recompile my code and most of the time it works
> again, sometimes recompiling more components that are involved does the
> trick, I don't know why, because nothing changed...
>
> 3.881 [ Info ][FixedObject] Thread created with scheduler type '0',
> priority 0 and period 0.
> 3.881 [ Info ][DeploymentComponent::loadComponent] Adding FixedObject
> as new peer: OK.
> 3.881 [ Warning][DeploymentComponent::loadComponents] Lowering scheduler
> type to SCHED_OTHER for non-privileged users..
> 3.881 [ Info ][DeploymentComponent::loadComponents] Added component
> FixedObject to group 0
> 3.882 [ Info ][Thread] Creating Thread for scheduler: 0
> [New Thread 0xaf693b70 (LWP 3780)]
> 3.882 [ Info ][CartesianMotion] Thread created with scheduler type
> '0', priority 0 and period 0.
> deployer-gnulinux:
> /home/u0065688/src/svn/robotics-ros/packages/cturtle_stacks/geometry/eigen/include/Eigen/src/Core/MatrixStorage.h:44:
> Eigen::ei_matrix_array<T, Size, MatrixOptions, Align>::ei_matrix_array()
> [with T = double, int Size = 36, int MatrixOptions = 2, bool Align =
> true]: Assertion `(reinterpret_cast<size_t>(array)& 0xf) == 0&& "this
> assertion is explained here:
> http://eigen.tuxfamily.org/dox/UnalignedArrayAssert.html **** READ THIS
> WEB PAGE !!! ****"' failed.
>
> Program received signal SIGABRT, Aborted.
> 0xb7fe1424 in __kernel_vsyscall ()
> (gdb) bt
> #0 0xb7fe1424 in __kernel_vsyscall ()
> #1 0xb7861941 in raise (sig=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #2 0xb7864e42 in abort () at abort.c:92
> #3 0xb785a8e8 in __assert_fail (
> assertion=0xb309e2cc "(reinterpret_cast<size_t>(array)& 0xf) == 0
> && \"this assertion is explained here:
> http://eigen.tuxfamily.org/dox/UnalignedArrayAssert.html **** READ THIS
> WEB PAGE !!! ****\"", file=0xb309e258
> "/home/u0065688/src/svn/robotics-ros/packages/cturtle_stacks/geometry/eigen/include/Eigen/src/Core/MatrixStorage.h",
>
> line=44,
> function=0xb30a8800 "Eigen::ei_matrix_array<T, Size, MatrixOptions,
> Align>::ei_matrix_array() [with T = double, int Size = 36, int
> MatrixOptions = 2, bool Align = true]") at assert.c:81
> #4 0xb2fec07b in ei_matrix_array (this=<value optimized out>, name=...)
> at
> /home/u0065688/src/svn/robotics-ros/packages/cturtle_stacks/geometry/eigen/include/Eigen/src/Core/MatrixStorage.h:43
> #5 ei_matrix_storage (this=<value optimized out>, name=...)
> at
> /home/u0065688/src/svn/robotics-ros/packages/cturtle_stacks/geometry/eigen/include/Eigen/src/Core/MatrixStorage.h:76
> #6 Matrix (this=<value optimized out>, name=...) at
> /home/u0065688/src/svn/robotics-ros/packages/cturtle_stacks/geometry/eigen/include/Eigen/src/Core/Matrix.h:309
> #7 iTaSC::CartesianMotion::CartesianMotion (this=<value optimized out>,
> name=...)
> at
> /home/u0065688/src/svn/robotics-ros/packages/private-kul-ros-pkg/iTaSC/src/CartesianMotion.cpp:49
> #8 0xb2fec2c4 in createComponent (instance_name=...) at
> /home/u0065688/src/svn/robotics-ros/packages/private-kul-ros-pkg/iTaSC/src/CartesianMotion.cpp:29
> #9 0xb7d65d9a in OCL::ComponentLoader::loadComponent (this=0x8076ac8,
> name=..., type=...)
> at
> /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/ocl/deployment/ComponentLoader.cpp:495
> #10 0xb7cd25c8 in OCL::DeploymentComponent::loadComponent
> (this=0xbfffea50, name=..., type=...)
> at
> /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/ocl/deployment/DeploymentComponent.cpp:1491
> #11 0xb7cd9d09 in OCL::DeploymentComponent::loadComponentsInGroup
> (this=0xbfffea50, configurationfile=..., group=0)
> at
> /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/ocl/deployment/DeploymentComponent.cpp:770
> #12 0xb7cdbc8f in OCL::DeploymentComponent::kickStart (this=0xbfffea50,
> configurationfile=...)
> at
> /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/ocl/deployment/DeploymentComponent.cpp:490
> #13 0x08052868 in main (argc=<value optimized out>, argv=0xbfffec74) at
> /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/ocl/bin/deployer.cpp:150
>
>
> line 29 of CartesianMotion.cpp states:
> ORO_CREATE_COMPONENT( iTaSC::CartesianMotion );
>
> line 49 is the last line of the following:
>
> CartesianMotion::CartesianMotion(const std::string& name) :
> SubTask(name, PreOperational),
> Kp_prop(VectorXd::Zero(6)),
> use_pose(true),
> rotation_type(RPY),
> rotation_ref(true),
> Wy_prop(std::vector<double>(6, 1.0)),
> ydot(6),
> Kp(VectorXd::Zero(6)),
> yd(VectorXd::Zero(6)),
> dyd(VectorXd::Zero(6)),
> ym(VectorXd::Zero(6)),
> Jf_kdl(6)
> {...
>
> Nick
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...<mailto:Orocos-Users [..] ...>
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>
>
> --
> Piotr Trojanek
>
Some info on Eigen and Orocos
2011/1/18 Dominick Vanthienen <nick [dot] vanthienen [..] ...>
>
>
> On 01/18/2011 10:36 AM, Piotr Trojanek wrote:
> > Have you tried this solution?
> http://eigen.tuxfamily.org/dox/StructHavingEigenMembers.html#how
> Thank you!
> This works (so far...)
>
According to the the above documentation, the EIGEN_MAKE_ALIGNED_OPERATOR_NEW
macro is needed only if you use FIXED size. So, I'm curious how that solved
your problem?
Philippe
Some info on Eigen and Orocos
This is the exact problem that has been described in this thread.
I (and others) list some possible solutions, so I would suggest that you
read the thread first !
Best regards,
Some info on Eigen and Orocos
I agree that EIGEN_DONT_ALIGN is a cheap (but fast) solution and I do not
like it at all.
I had also issues of alignment of Eigen data (which is even more tricky on
QNX)
and the only solution was to force EIGEN_DONT_ALIGN for this platform.
I think, that the real solution for Quaternion is a patch to the Eigen
sources.
Thanks for spotting and explaining this issue!
On Thu, Jan 13, 2011 at 12:05, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:
> On 01/13/2011 11:07 AM, Leopold Palomo-Avellaneda wrote:
> >> Moreover, as soon as you start using -DEIGEN_DONT_ALIGN (I think that's
> >> the right definition, but anyway), you have to be *really* sure that all
> >> libraries you are using are also compiled with that flag. Hardly robust
> >> in my opinion
> >
> > please, could you explain this? because, AFAIK Eigen is a pure template
> > library defined in the headers. So, if you use that define in a
> component, you
> > obj would be affected by that. But, I don't know if this will be affect
> in the
> > process to link against another library (eg. RTT).
> Well. Let's assume you have two libraries, A and B. A is compiled with
> DONT_ALIGN, B is not.
>
> A creates an Eigen::Vector3d -- which is therefore not aligned -- and
> passes it to B. Unfortunately, B requires its Eigen data structures to
> be aligned. Boom.
> --
> Sylvain Joyeux (Dr.Ing.)
> Space & Security 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
> -----------------------------------------------------------------------
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>