[Rock-dev] MulitlevelLaserScan base type integration

[Jakob Schwendner]

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.

 

 

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