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
--
Dipl. Inf. Janosch Machowinski
SAR- & Sicherheitsrobotik
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-6614
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: [email protected]
Weitere Informationen: http://www.informatik.uni-bremen.de/robotik
_______________________________________________
Rock-dev mailing list
[email protected]
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
