[Rock-dev] Another base type required: MultiLevelLaserScan

[Sascha Arnold]

It was not intended to add the MultiLevelLaserScan class in its current
form to the base types. Among other things it breaks with our unit
conventions, like the LaserScan class.

Am 19.11.2013 15:50, schrieb Matthias Goldhoorn:
>
> why not using the LaserScan from base::Types here it has a slight
> overhead, but would simplify the usage...
> Then you would not need to use VerticalMultilevelScan anymore.
It was mainly the overhead why I didn't want to use the Laserscan here.
It would be possible to use the Laserscan as vertical scan instead, but
the Laserscan class itself needs some improvements. (in particular units
in meter and the error handling)
> The naming is even wourse, Vertical is missleading the scanner could
> be aligned in every direction.
Horizontal entries are verticals scans. But yes it is a bit confusing.
>
> Then what's the current angle of a MultiLevelLaserScan, the "Vertical"
> angle is represended within horizontal_angle and start_angle and
> angular resolution give's the "vertical" angle with the index.
>
> But why not coding the current angle for the MultiLevelLaserScan the
> same way.
> -> giving start angle and anglar resolution, the index then give's the
> current angle.
> This should be done in the same way like the normal LaserScan.
This comes from the fact that the velodyne has discrete vertical angles,
but non-discrete horizontal angles. And I simply didn't want to loose
any information in the raw type.
But it is anyway the question how a common 3D laserscan base type should
look like. It could be discrete in both directions, than a 2D distance
image should do. Or not discrete at all, or a mixed form like this one.

>
> That's all from my side.
>
> Matthias
>
>
>
>
> On 19.11.2013 15:41, Stefan Haase wrote:
>> This type can be used to store scan data of velodyne-like laser-scanners.
>> http://spacegit.dfki.uni-bremen.de/dfki-drivers/velodyne_lidar/blobs/master/src/MultilevelLaserScan.h
>>
>>
>> It is used by graph_slam and will be used by MARS and the
>> corridor-navigation.
>>
>> Any comments, suggestions or concerns about adding it to base/types?
>>
>> Best regards,
>> Stefan
>>
>> -- 
>>  Dipl.-Inf. Stefan Haase
>>  Space Robotics and Animation
>>  
>> Standort Bremen:
>>  DFKI GmbH
>>  Robotics Innovation Center
>>  Robert-Hooke-Straße 5
>>  28359 Bremen, Germany
>>  
>>  Phone: +49 (0)421 178 45-4108
>>  Fax:   +49 (0)421 178 45-4150
>>  E-Mail: Stefan.Haase at dfki.de <mailto:Stefan.Haase 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
>>  -----------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Rock-dev mailing list
>> Rock-dev at dfki.de
>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>
>
> -- 
>  Dipl.-Inf. Matthias Goldhoorn 
>  Space and Underwater Robotic
>
>  Universität Bremen
>  FB 3 - Mathematik und Informatik
>  AG Robotik
>  Robert-Hooke-Straße 5
>  28359 Bremen, Germany
>
>  Tel.:     +49 421 178 45-4193
>  Zentrale: +49 421 178 45-6550
>  Fax:      +49 421 178 45-4150
>  E-Mail:   matthias.goldhoorn at uni-bremen.de
>
>  Weitere Informationen: http://www.informatik.uni-bremen.de/robotik
>
>
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20131120/7d8c5926/attachment-0001.htm