[Rock-dev] The future of LaserScan

[Jakob Schwendner]

On 08/31/2011 09:33 AM, Sylvain Joyeux wrote:
> 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 ?
LaserScan is one of the many base types that could be improved. I don't 
see a particular reason to go through the hassle now. Even if the code 
transition would be not too much work, the data conversion is. As long 
as we don't have a proper solution on that end, I would vote not to do 
it now. I would prefer to do one major overhaul of all base types "some 
time in the future"(tm). At least that would mean just breaking it once.

Jakob