This wasn't send to the ML. sry. Am 20.08.2014 um 15:34 schrieb Sascha Arnold: > >>>> 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). > For most sonars one will get all signal of all measurements in one > direction for a certain time span. In the hokuyo case one would get > optional multiple responses in different directions. >> >>>> 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. > Thats true. That drawback in using an end angle instead of the angular > resolution is that the resolution needs to be calculated and that it > is impossible to define a scan that it bigger than 360°. But I guess > that is acceptable. The case that the scan is equal to 360° has to be > defined when start and end angle are equal and the size of that > dimension is higher than one. > >> >>> 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. > Ah ok, now I got it. That would be possible if we don't define an > angular resolution. > The difference to the distance image would than be that the origin of > the frame is not on the image plane, but I guess that would be the > intended case. > >> >> Jakob >> >> >> >> >
-- Sascha Arnold Unterwasserrobotik Hauptgeschäftsstelle Standort Bremen: DFKI GmbH Robotics Innovation Center Robert-Hooke-Straße 1 28359 Bremen, Germany Tel.: +49 421 178 45-4197 Zentrale: +49 421 178 45-0 Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen) E-Mail: [email protected] Weitere Informationen: http://www.dfki.de/robotik ----------------------------------------------------------------------- Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.: DE 148646973 Steuernummer: 19/673/0060/3 ----------------------------------------------------------------------- _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
