wiki:WikiStart/OngoingWork/BaseTypesCleanup

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.

Motor/Joint state

joint state description

float vs. double

I did some benchmarking (code is in the eigen head bench/benchGeometry.cpp) for our most common Eigen operations and get the following results:

vec = trans * vec
float    Isometry        AutoAlign 3 0.0104s  
float    Isometry        DontAlign 3 0.0097s  
float    Isometry        AutoAlign 4 0.0147s  
float    Isometry        DontAlign 4 0.0091s  
float    Projective      AutoAlign 4 0.0092s  
float    Projective      DontAlign 4 0.0189s  
double   Isometry        AutoAlign 3 0.0102s  
double   Isometry        DontAlign 3 0.0099s  
double   Isometry        AutoAlign 4 0.0137s  
double   Isometry        DontAlign 4 0.0092s  
double   Projective      AutoAlign 4 0.0092s  
double   Projective      DontAlign 4 0.0180s  
vec = trans.matrix() * vec
float    Isometry        AutoAlign 4 0.0093s  
float    Isometry        DontAlign 4 0.0134s  
double   Isometry        AutoAlign 4 0.0094s  
double   Isometry        DontAlign 4 0.0135s  
trans = trans1 * trans
float    Isometry        AutoAlign   0.0232s  
float    Isometry        DontAlign   0.0208s  
double   Isometry        AutoAlign   0.0216s  
double   Isometry        DontAlign   0.0208s  
float    Projective      AutoAlign   0.0122s  
float    Projective      DontAlign   0.0398s  
double   Projective      AutoAlign   0.0183s  
double   Projective      DontAlign   0.0408s  
trans = trans1.matrix() * trans.matrix()
float    Isometry        AutoAlign   0.0122s  
float    Isometry        DontAlign   0.0499s  
double   Isometry        AutoAlign   0.0184s  
double   Isometry        DontAlign   0.0503s  

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

A quick test regarding the precision (program is attached):

Rotating the vector [1,0,0] with 2*PI/n n-times around z and then computing the difference to [1,0,0].
        Divider     Error float   Err. f. norm.    Error double   Err. d. norm. 
              1  0.000000000000  0.000000000000  0.000000000000  0.000000000000
             10  0.000000344992  0.000000435616  0.000000000000  0.000000000000
            100  0.000000678681  0.000000279328  0.000000000000  0.000000000000
           1000  0.000001369917  0.000001229855  0.000000000000  0.000000000000
          10000  0.000045075667  0.000000356038  0.000000000000  0.000000000000
         100000  0.000196589841  0.000000106481  0.000000000000  0.000000000000
        1000000  0.000027891458  0.000008616983  0.000000000000  0.000000000000

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.
  • fix libraries accordingly
  • add typedef SonarScan ???

MultiLaserScan

new type multi level laser scan description

RigidBodyState

  • sourceFrame and targetFrame does not follow naming convention
  • Discussion about merging TransformationWithUncertainty and RigidBodyState
    • One approach is:
      1. 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
      2. 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).
      3. 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)

MotionCommand

  • Time stamping is missing on all motion_commands

Done changes

SonarScan(done)

  • rename it to SonarBeam
  • rename variable sonarScan to sonar_beam
  • spelling: time_beetween_bins
  • add sound velocity
  • change getResolution, that it calculated with the local given value
  • add vertical_opening_angle
  • add horizontal_opening_angle
  • check naming conventions

Frame (done)

  • add modes for compressed images
  • remove iterators, convertToCvMat
  • add documentation
Last modified 5 years ago Last modified on 08/07/14 15:51:20

Attachments (1)

Download all attachments as: .zip