[Rock-dev] MulitlevelLaserScan base type integration

[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:*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.
>
>
>
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> 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:  jmachowinski at informatik.uni-bremen.de

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

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140127/d0d3b686/attachment-0001.htm