[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