Context Navigation

This page should list the issues identified at the moment with types in base/types, and the proposed solutions. In the mid-term, this will be used to schedule a redesign of the package and fix all these issues.

In any case, nothing will happen until we have a comprehensive and robust log migration tool available.

The result suggest, that there is currently something not working right with Isometry transforms (same for Affine). I've noted the Eigen developers on that. Assuming this is going to get fixed, trans * trans would be around 50% faster for floats, compared to double. It doesn't seem to make a difference for trans * vec.

So for the time being my position would be (subject to change of course :) ):

keep double for the transformation type

use floats for data-types with a a lot of data, e.g. maps scans and so on

At first glance the error seems not to be too big, but on the other hand it could have an effect in Kalman Filters and the like.
That would support the statement above.

usage of std::string

std::string is not hard-RT compatible

solution 1: define a minimal base::basic_string implementation that is based on std::vector

solution 2: extract the TLSF implementation out of RTT in a separate library. The problem with TLSF is that it requires a pre-allocated heap (i.e. you in principle need to know how much memory your process will need). According to people on orocos-dev, there are mechanism to do heap-reallocation at runtime if we run out of memory, but that would need to be implemented so that we don't break library code (which should not have to know that we're using TLSF in the first place). On the plus side, it would allow us to make the spline implementation hard-RT as well since it is currently making memory allocations behind the scenes (yuk).

LaserScan

change the type so that:

ranges are a std::vector<float> of values in meters

NaN is used for reading errors

Infinity is used for out-of-range errors

0 is used for "too near"

make minRange and maxRange floats, in meters

make sure that LaserScan providers that 0 is the center of the scan (i.e. the scan angles go into [-opening/2, opening/2]

rename the "ranges" field to distances, to make sure that not-migrated code breaks.

MultiLaserScan

RigidBodyState

Discussion about merging TransformationWithUncertainty and RigidBodyState

One approach is:

Keep rbs as it is for consistency, in order to have full information of a rbs (position, orientation and velocities(6D) wrt source frame). For info storage purposes

Create a transformation class with position and orientation (quaternion) with a 6 x 6 uncertainty matrix and use TransformationWithUncertainty to perform composition, inverse and apply transformation (angle-axis representation).

Remove rbs-acceleration since it is not extensively use. Take KDL approach for this kind of information (simple acc, torque and forces vectors with timestamp)