[Rock-dev] New type to represent 3D range measurements

[Sascha Arnold]

This wasn't send to the ML. sry.

Am 20.08.2014 um 15:34 schrieb Sascha Arnold:
>
>>>> So, which types should it cover?
>>>> LaserScan, DistanceImage and MultilevelLaserScan? What about the sonar
>>> types, they are also very similar.
>>> Of course sonar data can be stored also in that type, but some of 
>>> them may
>>> need some preprocessing. And it really depends on the type of sonar.
>>> Alex can tell more on that topic.
>>  From this and the comment from Mathias, the difference to me is 
>> really that there are multiple measurements per ray. This btw. Is 
>> supported now by the new hokuyos as well. Adding it to the datatype 
>> is a pain though. I guess would have to be handled similar to the 
>> MLS. Maybe we could add this feature with a templated base class 
>> later (list of floats instead of float for the ray values).
> For most sonars one will get all signal of all measurements in one 
> direction for a certain time span. In the hokuyo case one would get 
> optional multiple responses in different directions.
>>
>>>> Instead of making it interface so complex, why don't you use two
>>> std::vectors which specify the spacing for each row.
>>>> The vectors can have either two elements (for start and end) or as 
>>>> many as
>>> the dimension has samples in the grid.
>>>> No need for the cumbersome configuration with width irregular height
>>> irregular a.s.o.
>>> That was the first approach. Two vectors, where the first three 
>>> entries are
>>> the start angle, angular resolution and end angle. One could even 
>>> think about
>> This is what would make it complicated. Don't use three values. 
>> Angular resolution is implied from the size of the dimension.
>> If you only have two values, there is also not the problem that the 
>> input is ambiguous. If there are only two scans, they are the correct 
>> values for the position.
> Thats true. That drawback in using an end angle instead of the angular 
> resolution is that the resolution needs to be calculated and that it 
> is impossible to define a scan that it bigger than 360°. But I guess 
> that is acceptable. The case that the scan is equal to 360° has to be 
> defined when start and end angle are equal and the size of that 
> dimension is higher than one.
>
>>
>>> I also liked the other approach, since it was much more cleaner, but 
>>> I was
>>> going for that version to make the configuration easier not harder.
>> With the above change I don't see that it would be harder.
>>
>>>> What would be good though is to specify if the dimension is angular
>>> (velodyne) or distance (tof).
>>> Can you explain what you mean by that?
>> This is related to Pierres post. You need to specify if the position 
>> you provide is an angle (polar projection) as in e.g. the velodyne 
>> case, or if it’s a distance (planar projection) as in the TOF camera 
>> case. The reprojection models (xy position to beam) are different for 
>> the two cases, as stated by Pierre.
> Ah ok, now I got it. That would be possible if we don't define an 
> angular resolution.
> The difference to the distance image would than be that the origin of 
> the frame is not on the image plane, but I guess that would be the 
> intended case.
>
>>
>> Jakob
>>
>>
>>
>>
>

-- 
  Sascha Arnold
  Unterwasserrobotik

  Hauptgeschäftsstelle Standort Bremen:
  DFKI GmbH
  Robotics Innovation Center
  Robert-Hooke-Straße 1
  28359 Bremen, Germany

  Tel.:     +49 421 178 45-4197
  Zentrale: +49 421 178 45-0
  Fax:      +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
  E-Mail:   Sascha.Arnold at dfki.de

  Weitere Informationen: http://www.dfki.de/robotik
  -----------------------------------------------------------------------
  Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
  Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
  Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
  (Vorsitzender) Dr. Walter Olthoff
  Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
  Amtsgericht Kaiserslautern, HRB 2313
  Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
  USt-Id.Nr.:    DE 148646973
  Steuernummer:  19/673/0060/3
  -----------------------------------------------------------------------