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

Discussion:

Sascha Arnold

2014-08-19 16:37:07 UTC

Hi,
I just finished a first version of the new base type that can be used to
store 3D range measurements.
This is also the type that should replace the MultilevelLaserScan.

After some discussion with Alex I extended my first version to allow
different configurations regarding the angular resolution between the
scans. It leads to a bit more overhead but it is more flexible. It
allows to have:
- horizontal and vertical regular angles or
- horizontal irregular and vertical regular angles or
- horizontal regular and vertical irregular angles
This allows to store data from different kind of sensors, like the
velodyne, vertical or horizontal mounted 2D or everything that provides
a distance image.
The information is stored in a single vector in a row major form to
simplify the usage as a distance image.

Please have a look at the first version on my fork of base-types:
https://github.com/saarnold/base-types/commit/1796d23d002779639455d0ff3e4dd7876e404dad

I'll write a pull request as soon as it is complete. My next steps are
to adapt the visualization and to write the logfile conversion for the
old type.
If someone has a concern with something in that type please report it
now. Later it will be hard to change anything.
The name is currently Scan3D and is also open for discussion.

Best regards,
Sascha
--
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
-----------------------------------------------------------------------

Sylvain Joyeux

2014-08-19 18:38:00 UTC

Permalink

Two comments:
- the row/col terminology is really weird for such a data structure.
Especially since 'rows' are vertical and 'cols' horizontal
- I would prefer that the name says that the scan is a polar
representation. Scan3D feels wrong, but I don't really have a better
one.

Post by Sascha Arnold
Hi,
I just finished a first version of the new base type that can be used to
store 3D range measurements.
This is also the type that should replace the MultilevelLaserScan.
After some discussion with Alex I extended my first version to allow
different configurations regarding the angular resolution between the
scans. It leads to a bit more overhead but it is more flexible. It
- horizontal and vertical regular angles or
- horizontal irregular and vertical regular angles or
- horizontal regular and vertical irregular angles
This allows to store data from different kind of sensors, like the
velodyne, vertical or horizontal mounted 2D or everything that provides
a distance image.
The information is stored in a single vector in a row major form to
simplify the usage as a distance image.
https://github.com/saarnold/base-types/commit/1796d23d002779639455d0ff3e4dd7876e404dad
I'll write a pull request as soon as it is complete. My next steps are
to adapt the visualization and to write the logfile conversion for the
old type.
If someone has a concern with something in that type please report it
now. Later it will be hard to change anything.
The name is currently Scan3D and is also open for discussion.
Best regards,
Sascha
--
Sascha Arnold
Unterwasserrobotik
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
-----------------------------------------------------------------------
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

Alexander Duda

2014-08-19 22:19:49 UTC

Permalink

Post by Sylvain Joyeux
- the row/col terminology is really weird for such a data structure.
Especially since 'rows' are vertical and 'cols? horizontal

I think the documentation is misleading. Rows are horizontal and cols are vertical. The naming is derived from matrices which are used to represent the data and is consistent with opencv and eigen data structs which can easily be constructed from this type. Therefore, for the sake of consistency I would keep the name even if vertical, horizontal might be close to the physical sensor.

Alex

Post by Sylvain Joyeux
- I would prefer that the name says that the scan is a polar
representation. Scan3D feels wrong, but I don't really have a better
one.

_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

--
Dipl.-Ing. Alexander Duda
Unterwasserrobotik
Robotics Innovation Center

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

Tel.: +49 421 178 45-6620
Zentrale: +49 421 178 45-0
Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
E-Mail: Alexander.Duda 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140820/d653bc9b/attachment-0001.htm

Sascha Arnold

2014-08-20 09:11:35 UTC

Permalink

Hi Pierre,
ToF Cameras are definitely one use case of the data type.
I thought about the case with two irregular angle vectors too and I
couldn't think of a case that this would be needed. Since the
irregularity described by one horizontal set of angles has to be valid
for all other vertically transformed cases. Is that true in the case of
the ToF Camera?
It would be easy to add another optional vector to override the angles
both horizontally and vertically.

The true horizontally and vertically irregular case of course would need
an unique transformation or set of 3D polar coordinates. And that I
think is better represented by a vector of 3D polar measurements.

Best regards,
Sascha

Hi,

Distance images from common ToF Cameras are horizontally and vertically
irregular in respect to angles. The angles are the atan of a linear
function. Feel free to ignore me if that was not an intended use case.

Post by Sascha Arnold
The information is stored in a single vector in a row major form to
simplify the usage as a distance image.
https://github.com/saarnold/base-types/commit/1796d23d002779639455d0ff3e4dd7876e404dad
I'll write a pull request as soon as it is complete. My next steps are
to adapt the visualization and to write the logfile conversion for the
old type.
If someone has a concern with something in that type please report it
now. Later it will be hard to change anything.
The name is currently Scan3D and is also open for discussion.

Regards,
Pierre

--
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
-----------------------------------------------------------------------

Pierre Willenbrock

2014-08-20 10:26:07 UTC

Permalink

Hi Sascha,

the pointcloud from ToF Cameras can be produced using
[x*x_scale,y*y_scale,1]^T*depth, with x,y being integer pixel
coordinates and x_scale,y_scale constants. The angular representation
depends on the order of angular transformations. Usually, x=0 or y=0
results in atan(y*y_scale) or atan(x*x_scale), but things get a bit more
complex when deviating from the coordinate axis'.

Regards,
Pierre

Post by Sascha Arnold
Hi Pierre,
ToF Cameras are definitely one use case of the data type.
I thought about the case with two irregular angle vectors too and I
couldn't think of a case that this would be needed. Since the
irregularity described by one horizontal set of angles has to be valid
for all other vertically transformed cases. Is that true in the case of
the ToF Camera?
It would be easy to add another optional vector to override the angles
both horizontally and vertically.
The true horizontally and vertically irregular case of course would need
an unique transformation or set of 3D polar coordinates. And that I
think is better represented by a vector of 3D polar measurements.
Best regards,
Sascha

Hi,

Regards,
Pierre

Sascha Arnold

2014-08-20 09:35:32 UTC

Permalink

Hi Sylvain,
I thought about naming them horizontal_entries or horizontal_size too.
But an horizontal entry would of course be a vertical vector and I
recall that this terminology led to confusion in the old type. Thats why
I decided to use the matrix terminology. I'll think about renaming it or
improving the documentation.

In the opendfki wiki I already collected some naming proposals:
- SweepedLaserScan
- MultiLaserScan
- LaserScanArray
- MultiLevelLaserScan
- LaserScan2
- LaserScans
- Scan3D

Currently I prefer Scan3D. Feel free to vote or contribute.

Best regards,
Sascha

Post by Sylvain Joyeux
- the row/col terminology is really weird for such a data structure.
Especially since 'rows' are vertical and 'cols' horizontal
- I would prefer that the name says that the scan is a polar
representation. Scan3D feels wrong, but I don't really have a better
one.

Steffen Planthaber

2014-08-20 10:06:04 UTC

Permalink

Hi,

Technically the data represents a Depth Image, no matter which sensor
created it.

It contains an 2 dimesional array with the distances and information to
use in order to crate a pointcloud.

It has really nothing to to with a "scan".

The name DepthImage though is misleading because nobody expects an
"image" from a laser scanner.

So I'd name the class without using scan, as the information could also
come from TOF od stereo cams.

What about:
- DepthInformation
- Depth3D
- DepthMap <- from computer graphics: fits perfectly:
http://en.wikipedia.org/wiki/Depth_map

Thinking about this:

The start angle is not needed. The direction should be defined by the
middle of the "image", the start angle can be calculated by the
resolution or accumulated by the sum of irregular angles used.

Best, Steffen

Post by Sascha Arnold
Hi Sylvain,
I thought about naming them horizontal_entries or horizontal_size too.
But an horizontal entry would of course be a vertical vector and I
recall that this terminology led to confusion in the old type. Thats why
I decided to use the matrix terminology. I'll think about renaming it or
improving the documentation.
- SweepedLaserScan
- MultiLaserScan
- LaserScanArray
- MultiLevelLaserScan
- LaserScan2
- LaserScans
- Scan3D
Currently I prefer Scan3D. Feel free to vote or contribute.
Best regards,
Sascha

--
Steffen Planthaber
Weltraumrobotik

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

Tel.: +49 421 178 45-4125
Zentrale: +49 421 178 45-0
Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
E-Mail: Steffen.Planthaber 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
-----------------------------------------------------------------------

Jakob Schwendner

2014-08-20 11:12:35 UTC

Permalink

Post by Steffen Planthaber
- DepthInformation
- Depth3D
http://en.wikipedia.org/wiki/Depth_map

I like DepthMap as well, although Scan3D is likely more identifiable.

Post by Steffen Planthaber
The start angle is not needed. The direction should be defined by the
middle of the "image", the start angle can be calculated by the
resolution or accumulated by the sum of irregular angles used.

The good thing about having start and end values is that you can encode the complete camera matrix (center point and focal length).

Cheers,

Jakob

Jakob Schwendner

2014-08-20 09:37:36 UTC

Permalink

-----Original Message-----
From: rock-dev-bounces at dfki.de [mailto:rock-dev-bounces at dfki.de] On
Behalf Of Sascha Arnold
Sent: Dienstag, 19. August 2014 18:37
To: rock-dev at dfki.de
Subject: [Rock-dev] New type to represent 3D range measurements
Hi,
I just finished a first version of the new base type that can be used to store
3D range measurements.
This is also the type that should replace the MultilevelLaserScan.

So, which types should it cover?
LaserScan, DistanceImage and MultilevelLaserScan? What about the sonar types, they are also very similar.

After some discussion with Alex I extended my first version to allow different
configurations regarding the angular resolution between the scans. It leads
- horizontal and vertical regular angles or
- horizontal irregular and vertical regular angles or
- horizontal regular and vertical irregular angles This allows to store data from
different kind of sensors, like the velodyne, vertical or horizontal mounted
2D or everything that provides a distance image.
The information is stored in a single vector in a row major form to simplify the
usage as a distance image.

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.
What would be good though is to specify if the dimension is angular (velodyne) or distance (tof).

Also I would try to minimize the use of the word laser in there. Especially in the member names.

Cheers,

Jakob

Matthias Goldhoorn

2014-08-20 09:41:29 UTC

Permalink

Post by Jakob Schwendner
So, which types should it cover?
LaserScan, DistanceImage and MultilevelLaserScan? What about the sonar types, they are also very similar.

The Sonar information are quite different, the also has some opening
angles, and most important the have multiple remissions per ray.
The called "bins" are giving the strength of echo. See the SonarScan type.
I would prefer to keep this separated. We have a task which creates
laser-scan information out of a sonar scan.
But the data type itself should keep separated.

Best,
Matthias
--
Dipl.-Inf. Matthias Goldhoorn
Space and Underwater Robotic

Universit?t Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Stra?e 1
28359 Bremen, Germany

Zentrale: +49 421 178 45-6611

Besuchsadresse der Nebengesch?ftstelle:
Robert-Hooke-Stra?e 5
28359 Bremen, Germany

Tel.: +49 421 178 45-4193
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: matthias.goldhoorn at informatik.uni-bremen.de

Weitere Informationen: http://www.informatik.uni-bremen.de/robotik

Jakob Schwendner

2014-08-20 11:06:58 UTC

Permalink

Post by Jakob Schwendner

Post by Jakob Schwendner
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.

Matthias Goldhoorn

2014-08-20 11:49:56 UTC

Permalink

There is a difference again, the sonars give information for EACH
possible value.
So the distance information is determined by the index of the array, the
strenth is the value of the given index.
The LaserScanners in opposite are representing multiple echos, and on
another vector the strength.
I also don't like the idea of handling sonars as LaserScans directly.
There are so much research done which tries to interprets sonars as
laser-scans but i thing this is the wrong direction.
I completely understand that you want to reduce the amount of data types
but this is not the best to start ;).

Best,
Matthias

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).

--
Dipl.-Inf. Matthias Goldhoorn
Space and Underwater Robotic

Universit?t Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Stra?e 1
28359 Bremen, Germany

Zentrale: +49 421 178 45-6611

Besuchsadresse der Nebengesch?ftstelle:
Robert-Hooke-Stra?e 5
28359 Bremen, Germany

Tel.: +49 421 178 45-4193
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: matthias.goldhoorn at informatik.uni-bremen.de

Weitere Informationen: http://www.informatik.uni-bremen.de/robotik

Jakob Schwendner

2014-08-20 12:06:03 UTC

Permalink

-----Original Message-----
From: rock-dev-bounces at dfki.de [mailto:rock-dev-bounces at dfki.de] On
Behalf Of Matthias Goldhoorn
Sent: Mittwoch, 20. August 2014 13:50
To: rock-dev at dfki.de
Subject: Re: [Rock-dev] New type to represent 3D range measurements
There is a difference again, the sonars give information for EACH possible
value.
So the distance information is determined by the index of the array, the
strenth is the value of the given index.
The LaserScanners in opposite are representing multiple echos, and on
another vector the strength.
I also don't like the idea of handling sonars as LaserScans directly.
There are so much research done which tries to interprets sonars as laser-
scans but i thing this is the wrong direction.
I completely understand that you want to reduce the amount of data types
but this is not the best to start ;).

I don't want to push too much on merging the sonar as well, since I find the other points more relevant.
Also to note is that in principle all of the types have in common that they are 2D maps. This also includes images btw. Since typelib supports inheritance now, how about basing all of them on one base class, similar to how this was done in envire.... I think I am getting ahead of myself here, though.

For practicality's sake I agree with you for now :) In perspective (I am thinking Entern here) I would like to start developing a lib for 2D grids, which could be used in this context.

Jakob

Sascha Arnold

2014-08-20 13:35:43 UTC

Permalink

This wasn't send to the ML. sry.

Post by Jakob Schwendner

Post by Jakob Schwendner
So, which types should it cover?
LaserScan, DistanceImage and MultilevelLaserScan? What about the sonar

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.

Post by Jakob Schwendner

Post by Jakob Schwendner
Instead of making it interface so complex, why don't you use two

std::vectors which specify the spacing for each row.

Post by Jakob Schwendner
The vectors can have either two elements (for start and end) or as
many as

the dimension has samples in the grid.

Post by Jakob Schwendner
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.

Post by Jakob Schwendner
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.

Post by Jakob Schwendner

Post by Jakob Schwendner
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