| | 1 | = Using Eigen types in Rock = |
| | 2 | |
| | 3 | Rock is based extensively on Eigen types. |
| | 4 | |
| | 5 | In libraries, the [http://eigen.tuxfamily.org/dox-2.0/StructHavingEigenMembers.html normal Eigen rules apply] |
| | 6 | |
| | 7 | In components, there are two constraints: |
| | 8 | 1. Eigen types should not have any alignment requirements |
| | 9 | 2. they should be registered as [http://rock-robotics.org/orogen/opaque_types.html opaque types] in oroGen |
| | 10 | |
| | 11 | == 1. Removing alignment requirements from Eigen types == |
| | 12 | |
| | 13 | Eigen's fixed-size Matrix type can be marked as non-aligned (and therefore not vectorized). Benchmarking showed that for small vectors (< 10 elements) it has no negative impact (and even has a small positive impact). |
| | 14 | |
| | 15 | This is done by providing the fourth template parameter as Eigen::DontAlign. For instance, Vector4 is defined |
| | 16 | |
| | 17 | In Rock, these "dont't align" types are defined in the [http://www.rock-robotics.org/package_directory/packages/base_types/index.html base/types] package, in base/eigen.h. We are using the same typedefs as Eigen itself, but put inside the base:: namespace. |
| | 18 | |
| | 19 | For instance, the non-aligned version of Eigen::Vector4d is base::Vector4d. |
| | 20 | |
| | 21 | '''Using the base variants of the types is encouraged, but not mandatory, in rock libraries.''' |
| | 22 | |
| | 23 | '''In Eigen 2.x, one cannot do that for Quaternion. Eigen 3.x does have that ability, but is not yet integrated in Rock''' |
| | 24 | |
| | 25 | == 2. Publishing the types in oroGen == |
