Adding sensor_msgs/RadarScan.

[JWhitleyWork]

sensor_msgs/RadarScan represents all of the detections measured in a single scan of a scanning radar.

I'm guessing this will open up a can of worms related to Euclidean vs polar coordinates but I could be wrong. See the notes in the message definition.

[lucasw]

How about modelling this after LaserScan, but extended to handle 2D arrays (making it polar) and doppler velocity?

Also time_increment- the mechanically rotating laser scanners are slow enough for that to be important.

The laser scanners that don't fit into the LaserScan mold (e.g. Velodyne, multi-layer SICK) are publishing PointClouds (which don't have the information that time_increment captures) plus product specific message formats that live in driver repositories (which maybe have all the information but only product specific subscribing nodes can use it). For radar would the main purpose for a common_msg be to incorporate the velocity information into object detection or state estimation nodes and visualize it in rviz in a generic way?

[JWhitleyWork]

@lucasw - The problem with doing this is the point information. To capture the 3-dimensional polar location of the center of the radar return, I would need to define angle, zenith, and radial range for every point. It makes sense to do this in a similar way to Point or Point32, but for polar. However, does that mean we should create a PolarPoint with these properties? What about PolarVelocity to capture the doppler velocity information in the correct format? This is the can of worms I mentioned with polar coordinates.

As for why I would like this included - it is to create a common message format for all radar driver types. The idea being that, if you have 3 or 4 different radars on a vehicle, you could do some sensor fusion with all of them regardless of vendor (because some vendors have better radars for given distances, materials, use cases, etc. than others). Visualization in rviz would also be a nice plus because it is incredibly non-standard right now.

[tfoote]

As I mentioned on discourse I'd strongly recommend that we not start trying to invent a Radar message from scratch but find some that are already implemented and have been debugged and tested on actively developed systems to make sure that we're capturing useful data.

[dejanpan]

@JWhitleyAStuff I know that this type of information can be sensitive but would Delphi be willing to share their interface? It also seems that you guys already have a ROS driver for their sensor: https://autonomoustuff.com/product/delphi-esr-2-5-24v/?

Or does this PR already include Delphi's message interface?

[JWhitleyWork]

@dejanpan and @tfoote - Very sorry for taking so long to respond. AFAIK, and AFAICF (with some Googling) AutonomouStuff is the only organization with a functional, somewhat widely-used driver for a radar. The main reason is that our driver is closed-source and Delphi/Continental/Bosch/Autoliv/etc. are not at all interested in anyone having their DBCs or interface docs given to anyone other than their customers, who sign NDAs. That being said, our open-source message formats are included here and here. Both contain similar messages to the one that I offered in this PR (delphi_esr_msgs/EsrTrack and radar_msgs/RadarTrack resp.).

Perhaps since AS and its customers are the primary targets for this type of message (no pun intended) it doesn't make sense to have it included in common_msgs yet. I know there are tons of other organizations (again, all AS customers) who are doing their own development for radar but their usage of ROS is questionable.

Thoughts?

[JWhitleyWork]

Since there is a lot of disagreement about the inclusion of these messages (and since @tfoote seems to think there are others out there, even though I can't find and don't have knowledge of anyone else using them outside of a proprietary setting), I'm closing this PR.