[Rock-dev] The future of LaserScan
Sylvain Joyeux
sylvain.joyeux at dfki.de
Wed Aug 31 09:33:19 CEST 2011
I know this is going to be a painful discussion and transition, but
LaserScan's usage of integers for distances is really bad.
The issue, obviously, is that it is a widely used type (backward
compatibility code-wise) and we have significant amount of data
(backward compatibility data-wise)
Since the LaserScan type itself provides helper methods to read
information, we could I guess break backward compatibility code-wise.
However, the data one is more problematic.
What I would propose is therefore:
* wait for having the log convertion tooling ready before doing anything
* 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
Thoughts ?
Sylvain
More information about the Rock-dev
mailing list