Since we're (at BIR) are getting very much in sonar processing, we thought it would be good to revisit the sonar data structures
The goal would be to have a single data structure for both multibeam and mechanical scanning sonars, and to fix the quirks of the current data structures, which are mostly, out of the top of my head: - unnormalized bin values (one byte is not enough to pre-normalize the data in case of high gains) - weird optional layout (for multibeam) I personally was very optionated against reusing one of the laserscan-class types, as sonar data is very different than laserscan data (one is mostly echo-range plus optionally remission the other is only about remission, and one is mostly single-echo and the other is multi-echo by nature). Nonetheless, since Sascha went already through the pain of getting a clean DepthMap type, and because I remembered that DepthMap has a feature set close to the ones a sonar type would need, I went through it. There's a lot of commonality which leads to two strategies: - reuse the DepthMap type (extending it through subclassing to add metadata specific to sonars such as beam shape parameters). It would look a bit awkward: there's no "depth measurement state" for sonars, and there are no echo distances (data would be in 'remission' instead of in 'distances'). 'Vertical' would mean 'Depth'. The current non-data API related to state and conversions to pointclouds would be meaningless (would even crash since there are no distances). - create a separate type, but heavily inspired from DepthMap Sylvain _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
