Standard proposal for marine radar messages. #4
Conversation
| # to be used separately. | ||
|
|
||
| float32[] echoes # Regularly spaced series of intensities from closest to | ||
| # farthest. Each array represents data from the same |
There was a problem hiding this comment.
The wording here is a bit cumbersome. It talks about "each array", implying there are multiple arrays, but this message only contains one array. I guess it should be interpreted relative to the RadarSector message, but that information is missing here.
I would also add an explanation to the regular spacing. Definition of the spacing is also information to be extracted from the "parent" message, but it is not mentioned here.
| # | ||
| # in frame frame_id, angles are measured around | ||
| # the positive Z axis (counterclockwise, if Z is up) | ||
| # with zero angle being forward along the x axis |
There was a problem hiding this comment.
Please unify the case of the axis names: Z vs x. Choose one case (I'd prefer uppercase).
| # This message is a submessage of RadarSector and is not intended | ||
| # to be used separately. | ||
|
|
||
| float32[] echoes # Regularly spaced series of intensities from closest to |
There was a problem hiding this comment.
Here, the note about device-specific units from RadarSector should be repeated.
| float32 angle_start # start angle of this sector [rad] | ||
| float32 angle_increment # angular distance between measurements [rad] | ||
|
|
||
| duration time_increment # time between rays [seconds] - if your scanner |
There was a problem hiding this comment.
In angle_increment, you use "measurements" and here "rays". It might be good to unify this terminology.
| float32 angle_increment # angular distance between measurements [rad] | ||
|
|
||
| duration time_increment # time between rays [seconds] - if your scanner | ||
| # is moving, this will be used in interpolating |
There was a problem hiding this comment.
| # is moving, this will be used in interpolating | |
| # is moving, this can be used in interpolating |
| duration scan_time # time between two consecutive complete scans | ||
| # or revolutions [seconds] | ||
|
|
||
| # Warning: On hardware that doesn't provide a timestamp |
There was a problem hiding this comment.
| # Warning: On hardware that doesn't provide a timestamp | |
| # Warning: On hardware that doesn't provide a timestamp, |
| float32 range_min # range of first sample in each ray [m] | ||
| float32 range_max # range of last sample in each ray [m] |
There was a problem hiding this comment.
| float32 range_min # range of first sample in each ray [m] | |
| float32 range_max # range of last sample in each ray [m] | |
| float32 range_min # range of the first sample in each ray [m] | |
| float32 range_max # range of the last sample in each ray [m] |
There was a problem hiding this comment.
Also, "ray" vs. "measurement" vs. "intensities".
| float32 range_min # range of first sample in each ray [m] | ||
| float32 range_max # range of last sample in each ray [m] | ||
|
|
||
| RadarEcho[] intensities # intensity data [device-specific units]. |
There was a problem hiding this comment.
Is there really no physically-sensible unit these values could be converted to? What are the units called in datasheet? dB, W, something else? I can also imagine converting the values to percentages of the emitted ray (log) power or something similar... Lidars usually report intensity as integers 0-100 or 0-255 (although I don't think this is standardized anywhere).
There was a problem hiding this comment.
Is there really no physically-sensible unit these values could be converted to? What are the units called in datasheet? dB, W, something else? I can also imagine converting the values to percentages of the emitted ray (log) power or something similar... Lidars usually report intensity as integers 0-100 or 0-255 (although I don't think this is standardized anywhere).
In the case of the radar I am using, the protocol was reversed-engineered (mostly by the OpenCPN community) so it's not clear what units are used.
|
Replaced by: apl-ocean-engineering/marine_msgs#40 |
Work on achieving #1