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 ==
[./JointState 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 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 ==
[./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