<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello,<br>
sry for the long delay, I didn't had the time to proceed with this
issue until now.<br>
<br>
On the basis of our last discussion I have created a proposal for
the new type in the wiki: <br>
<a class="moz-txt-link-freetext" href="http://rock.opendfki.de/wiki/WikiStart/OngoingWork/BaseTypesCleanup/MultiLaserScan">http://rock.opendfki.de/wiki/WikiStart/OngoingWork/BaseTypesCleanup/MultiLaserScan</a><br>
<br>
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.<br>
<br>
Currently one could inherit this type from a new LaserScan type,
since it is not that different anymore.<br>
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.<br>
<br>
Best regards,<br>
Sascha<br>
<br>
<div class="moz-cite-prefix">Am 27.01.2014 um 12:45 schrieb Jakob
Schwendner:<br>
</div>
<blockquote cite="mid:00fc01cf1b55$41656d50$c43047f0$@dfki.de"
type="cite">
<pre wrap="">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
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:rock-dev-bounces@dfki.de">rock-dev-bounces@dfki.de</a> [<a class="moz-txt-link-freetext" href="mailto:rock-dev-bounces@dfki.de">mailto:rock-dev-bounces@dfki.de</a>] On
Behalf Of Sylvain Joyeux
Sent: Montag, 27. Januar 2014 12:30
To: <a class="moz-txt-link-abbreviated" href="mailto:rock-dev@dfki.de">rock-dev@dfki.de</a>
Subject: Re: [Rock-dev] MulitlevelLaserScan base type integration
There is an option 4, which is having what information is currently stored
</pre>
</blockquote>
<pre wrap="">in
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">velodyne,
</pre>
<blockquote type="cite">
<pre wrap=""><float> might really be a better idea ...) as data structure. One can then
</pre>
</blockquote>
<pre wrap="">get
</pre>
<blockquote type="cite">
<pre wrap="">accessors to extract LaserScan structures if needed.
I personally feel that the overhead of using base::LaserScan is way too
</pre>
</blockquote>
<pre wrap="">big:
</pre>
<blockquote type="cite">
<pre wrap=""> - we get identical scan header information in each scan
- we get as many std::vector (i.e. heap allocation and memcpy of
</pre>
</blockquote>
<pre wrap="">*disjoint*
</pre>
<blockquote type="cite">
<pre wrap="">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: <a class="moz-txt-link-abbreviated" href="mailto:sylvain.joyeux@dfki.de">sylvain.joyeux@dfki.de</a>
Weitere Informationen: <a class="moz-txt-link-freetext" href="http://www.dfki.de/robotik">http://www.dfki.de/robotik</a>
-----------------------------------------------------------------------
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
<a class="moz-txt-link-abbreviated" href="mailto:Rock-dev@dfki.de">Rock-dev@dfki.de</a>
<a class="moz-txt-link-freetext" href="http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev">http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
Rock-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Rock-dev@dfki.de">Rock-dev@dfki.de</a>
<a class="moz-txt-link-freetext" href="http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev">http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev</a>
</pre>
</blockquote>
<br>
<div class="moz-cite-prefix">Am 27.01.2014 um 10:48 schrieb Janosch
Machowinski:<br>
</div>
<blockquote cite="mid:52E62B83.5030407@dfki.de" type="cite">
<div class="moz-cite-prefix">Hi,<br>
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)<br>
<br>
Option two sound the best to me. In this case the new LaserScan
should be designed to seperate the header from the data<br>
to avoid the problem with the old type.<br>
<br>
I don't like option 3, we would loose precision. And the
information if single lines are 'consistent' (taken in one
shot).<br>
Anyway the consistent thing was always implicit, I would like it
to be marked explicit in the data structure.<br>
Greetings<br>
Janosch<br>
<br>
On 27.01.2014 10:02, Jakob Schwendner wrote:<br>
</div>
<blockquote cite="mid:00c001cf1b3e$723434a0$569c9de0$@dfki.de"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi
Sascha,<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US">difficult. All 3 are good options.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US">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? <o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US">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. <o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US">So my vote would go for option 1 with a
transition to option 3 later.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US">Jakob<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue
1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"
lang="EN-US">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"
lang="EN-US"> <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:rock-dev-bounces@dfki.de">rock-dev-bounces@dfki.de</a>
[<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="mailto:rock-dev-bounces@dfki.de">mailto:rock-dev-bounces@dfki.de</a>]
<b>On Behalf Of </b>Sascha Arnold<br>
<b>Sent:</b> Dienstag, 21. Januar 2014 11:32<br>
<b>To:</b> <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:rock-dev@dfki.de">rock-dev@dfki.de</a><br>
<b>Subject:</b> [Rock-dev] MulitlevelLaserScan base
type integration<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hi,<br>
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.<br>
<br>
The current version of the MulitlevelLaserScan needs to be
improved, if it should become a base type. <br>
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.<br>
<br>
In my opinion there are three possible ways of doing that:<br>
<br>
1. Using the current LaserScan in the MulitlevelLaserScan
and change them together in the future. That would look
like this:<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal">struct MultilevelLaserScan<br>
{<br>
MultilevelLaserScan() : time(base::Time::now()) {};<br>
<br>
base::Time time;<br>
<br>
std::vector< base::samples::LaserScan > scans;<br>
<br>
std::vector< base::Angle > angles;<br>
};<o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"><br>
2. Define and use a improved LaserScan inside the
MulitlevelLaserScan and change the current LaserScan
with the new one later.<br>
<br>
</span>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.<br>
<br>
Personally I would prefer the first option for now. <br>
Instead of a single angle a quaternion could be used to be
more flexible. <span lang="EN-US">But I don't know if
there are any practical cases for that.</span><span
style="color:#1F497D" lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US"><o:p> </o:p></span></p>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Rock-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Rock-dev@dfki.de">Rock-dev@dfki.de</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev">http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev</a>
</pre>
</blockquote>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
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: <a class="moz-txt-link-abbreviated" href="mailto:Sascha.Arnold@dfki.de">Sascha.Arnold@dfki.de</a>
Weitere Informationen: <a class="moz-txt-link-freetext" href="http://www.dfki.de/robotik">http://www.dfki.de/robotik</a>
-----------------------------------------------------------------------
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
-----------------------------------------------------------------------</pre>
</body>
</html>