Thanks for your input Tully, it’s much appreciated.
I like the idea of easily adapting existing pipelines so I’m taking another look at sensor_msgs/MultiEchoLaserScan.
I’ll first point out that the only reason for how I split up the metadata between RadarSector and RadarScanline is that it mimics the structure of the data from the particular radar I was using so I have no reason to stick to this layout to make this a standard message.
That radar sends UDP packets covering a handful of spokes (maybe 16 or 32, covering about 1 or 2 degrees per packet if I remember correctly). A few dozen packets would be sent for a complete revolution of the radar. The RadarSector message represents one such packet in my case. By continuously displaying those RadarSector messages on an operator’s display as they arrive, you get an animated radar sweeping effect as the radar spins at a 60 rpm or less. Until we can trust that the robot can correctly understand the radar, this is an important display to have for the human operators.
What this means is that for a complete scan, multiple RadarSector messages are needed and I don’t have an overarching message to represent that. I could be wrong, but I suspect that a MultiEchoLaserScan message would contain a complete scan?
Assuming we use the exact same structure as MultiEchoLaserScan, I’ll list some of the considerations that occur to me as I adapt it to the radar with which I have experience, the Simarad Halo.
Header timestamp: “timestamp in the header is the acquisition time of the first ray in the scan.”
The radar I’m using doesn’t know anything about time so the time a packet is received is what we have to work with. A driver could estimate the time of the first ray, but it would be a guess.
angle_min, angle_max, angle_increment: The Halo reports an angle per spoke, but a driver could calculate min, max and increment from those since they are regularly spaced (I hope!).
time_increment, scan_time: I’m not sure what’s the difference between the two, but I suspect a driver could calculate those from the incoming data.
ranges and intensities: Am I correct to assume only hits are recorded for laser scans? This differs from the data we get from the Halo radar which is the full timeseries along a spoke, regularly spaced. Of course, in open water on a calm day, most of those returns are zero, so only recording the returns above a threshold could be more efficient but we might miss some of the structural info. What I mean is that if we allow sparse data, we make it harder to tell which pixels are neighbors or not. One option is to leave ranges empty and always report all the intensities.
Let me think about this for a bit… Of course, and other insights are apreciated!