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: [email protected] [mailto:[email protected]] On
Behalf Of Sylvain Joyeux
Sent: Montag, 27. Januar 2014 12:30
To: [email protected]
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: [email protected]
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
[email protected]
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
_______________________________________________
Rock-dev mailing list
[email protected]
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:*[email protected] [mailto:[email protected]] *On
Behalf Of *Sascha Arnold
*Sent:* Dienstag, 21. Januar 2014 11:32
*To:* [email protected]
*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
[email protected]
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: [email protected]
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
[email protected]
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
