[Rock-dev] MulitlevelLaserScan base type integration
Sascha Arnold
sascha.arnold at dfki.de
Thu Aug 7 16:38:02 CEST 2014
Hello,
sry for the long delay, I didn't had the time to proceed with this issue
until now.
On the basis of our last discussion I have created a proposal for the
new type in the wiki:
http://rock.opendfki.de/wiki/WikiStart/OngoingWork/BaseTypesCleanup/MultiLaserScan
I'm against merging this type with the distance image, since in my
opinion the mix of regular and irregular scan angles would only lead to
confusion without having any gain. One could add a method to create a
distance image from a MultiLaserScan type, but that would either filter
the data or stuff the distance image with empty entries.
Currently one could inherit this type from a new LaserScan type, since
it is not that different anymore.
I could write a second proposal doing that, but that means to change the
LaserScan type soon too or better to have a second newer LaserScan type
simultaneously.
Best regards,
Sascha
Am 27.01.2014 um 12:45 schrieb Jakob Schwendner:
> I guess you could see it as an extension of option 3, the image type, with
> the additional information of having irregular scan angles. As I said, I
> personally like this. But it should definitely merged with the distance
> image then, because they are really similar. The difference is that one has
> a polar projection and the other a pinhole model.
>
> Cheers,
>
> Jakob
>
>> -----Original Message-----
>> From: rock-dev-bounces at dfki.de [mailto:rock-dev-bounces at dfki.de] On
>> Behalf Of Sylvain Joyeux
>> Sent: Montag, 27. Januar 2014 12:30
>> To: rock-dev at dfki.de
>> Subject: Re: [Rock-dev] MulitlevelLaserScan base type integration
>>
>> There is an option 4, which is having what information is currently stored
> in
>> the "laser scan header" as common information in the new type, one
>> std::vector<base::Angle> for angle for each scan and just have a
>> std::vector<float> (or <double>, but given the data rate of e.g. the
> velodyne,
>> <float> might really be a better idea ...) as data structure. One can then
> get
>> accessors to extract LaserScan structures if needed.
>>
>> I personally feel that the overhead of using base::LaserScan is way too
> big:
>> - we get identical scan header information in each scan
>> - we get as many std::vector (i.e. heap allocation and memcpy of
> *disjoint*
>> memory) as there are scans
>>
>> Remember that we are talking about ~20 000 scans per second in the case of
>> the velodyne! To give a comparison, the hokuyo gives 40 scans per second.
>>
>> Even if I am personally such a big fan of the idea, we could factor the
>> common header laser scan information in a LaserScanBase class that is
>> inherited by both the MultiLevel and the plain LaserScan
>>
>> Outline of this proposal
>>
>> struct TheNameOfTheNewDataStructure
>> {
>> // Some data that I forget
>>
>> /** The time per-scan */
>> std::vector<base::Time> scan_times;
>> /** The angle-per-scan */
>> std::vector<base::Angle> scan_angles;
>> /** Start angle of a single scan */
>> base::Angle start_angle;
>> /** Angular step in a single scan */
>> base::Angle step;
>> /** Number of samples in a single scan */
>> boost:uint32_t step_count;
>> /** The data itself. The data for scan n is in
>> * samples[step_count * n] .. samples[step_count * (n+1)]
>> */
>> std::vector<float> samples;
>> };
>>
>>
>> --
>> Dr. Ing. Sylvain Joyeux
>> Space and Security Robotics
>>
>> Besuchsadresse der Nebengeschäftstelle:
>> DFKI GmbH
>> Robotics Innovation Center
>> Robert-Hooke-Straße 5
>> 28359 Bremen, Germany
>>
>> Postadresse der Hauptgeschäftsstelle Standort Bremen:
>> DFKI GmbH
>> Robotics Innovation Center
>> Robert-Hooke-Straße 1
>> 28359 Bremen, Germany
>>
>> Phone: +49 421 178 45-4136
>> Zentrale: +49 421 178 45-0
>> Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
>> E-Mail: sylvain.joyeux 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
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
Am 27.01.2014 um 10:48 schrieb Janosch Machowinski:
> Hi,
> option one is ok, but I don't like the overhead of the laserScan.
> (AFAIK we have a full header for every 32 scan lines)
>
> Option two sound the best to me. In this case the new LaserScan should
> be designed to seperate the header from the data
> to avoid the problem with the old type.
>
> I don't like option 3, we would loose precision. And the information
> if single lines are 'consistent' (taken in one shot).
> Anyway the consistent thing was always implicit, I would like it to be
> marked explicit in the data structure.
> Greetings
> Janosch
>
> On 27.01.2014 10:02, Jakob Schwendner wrote:
>>
>> Hi Sascha,
>>
>> difficult. All 3 are good options.
>>
>> To me option 1 sounds ok, because it would be the most simple
>> solution for now. Not sure about the name. How about
>> SweepedLaserScan, or just MultiLaserScan, or LaserScanArray?
>>
>> I prefer option 3 from a code point of view, though. I would try to
>> have all distance image types to be some form of image.
>>
>> So my vote would go for option 1 with a transition to option 3 later.
>>
>> Cheers,
>>
>> Jakob
>>
>> *From:*rock-dev-bounces at dfki.de [mailto:rock-dev-bounces at dfki.de] *On
>> Behalf Of *Sascha Arnold
>> *Sent:* Dienstag, 21. Januar 2014 11:32
>> *To:* rock-dev at dfki.de
>> *Subject:* [Rock-dev] MulitlevelLaserScan base type integration
>>
>> Hi,
>> some time ago we already had a short discussion on that topic but
>> didn't finish and I'd like to catch up on this now.
>>
>> The current version of the MulitlevelLaserScan needs to be improved,
>> if it should become a base type.
>> Basically this type should be a 3D version of the 2D Laserscan. As
>> far as I know the LaserScan itself should be improved on long term,
>> mainly because the units are not in meter and the range error should
>> be a separated state.
>>
>> In my opinion there are three possible ways of doing that:
>>
>> 1. Using the current LaserScan in the MulitlevelLaserScan and change
>> them together in the future. That would look like this:
>>
>> struct MultilevelLaserScan
>> {
>> MultilevelLaserScan() : time(base::Time::now()) {};
>>
>> base::Time time;
>>
>> std::vector< base::samples::LaserScan > scans;
>>
>> std::vector< base::Angle > angles;
>> };
>>
>>
>> 2. Define and use a improved LaserScan inside the MulitlevelLaserScan
>> and change the current LaserScan with the new one later.
>>
>> 3. Discretize both angles: Define a distance image type that can be
>> used for laser scan data. This comes closest to a 3D version of the
>> Laserscan, but that would mean to filter the data already in the
>> sample type, since most 3D lidars are a combination of a 2D lidar
>> with a (not so accurate) servo or motor. This is also true in the
>> Velodyne case.
>>
>> Personally I would prefer the first option for now.
>> Instead of a single angle a quaternion could be used to be more
>> flexible. But I don't know if there are any practical cases for that.
>>
>>
>>
>> _______________________________________________
>> Rock-dev mailing list
>> Rock-dev at dfki.de
>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
--
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
-----------------------------------------------------------------------
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140807/0d8d73cc/attachment.htm
More information about the Rock-dev
mailing list