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
