> > 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. 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).
> > 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. > 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. > 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. > > 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. Jakob _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
