Addition of Radar-Specific Message(s) to sensor_msgs

General
1

I work for a company that is very closely tied to the automotive industry. Many people in our industry are starting to use ROS as the basis for research and development efforts into autonomous vehicles. One of the primary sensing modalities is radar. Unfortunately, there isn’t really a basic message type in sensor_msgs that currently fits the output from a radar. The closest available is sensor_msgs/Range. However, while there are field_of_view, min_range, max_range and range properties associated with a radar detection, there are also other intrinsic properties like amplitude (a measure of the power of the returned signal - also applies to the other light-based sensor readings represented by Range) and angle (the angle of the detection within the lateral field of view - since radars have horizontal discrimination). Soon, there will also be 3D radars with vertical discrimination necessitating a splitting of field_of_view into lateral and vertical components.

Furthermore, many radars do not actually output the raw detection information but only output “tracks” which are filtered and grouped abstractions of single or multiple detections. Because of the tracking over several scans, they contain all the same readings as sensor_msgs/Range with the following exceptions:

  1. They do not contain “amplitude” since this is meaningless for a grouped/tracked single or set of detections.
  2. They also contain the following additional fields:
    a. lateral_rate: The lateral velocity of the object within the arc of the field of view of the radar (polar lateral velocity).
    b. width: A lateral measurement of the “track” from the most extreme lateral detections that make up the track.
    c. range_rate: A measurement of the longitudinal velocity of the track with respect to the detected angle (polar longitudinal velocity).
    d. range_accel: A measurement of the longitudinal acceleration of the track with respect to the detected angle.

We have our own versions of messages representing these data (see our package on Github [1] - specifically RadarDetection and RadarTrack) but I am now aware that these do not comply with REP 117 [2] and would much rather contribute to the standardized set of messages in common_msgs.

To the point: Does it make sense to try to extend sensor_msgs/Range to include the properties of a radar detection or should a new message be created? What about a track (when they are the only data available)?

[1] https://github.com/astuff/platform_automation_msgs/tree/master/radar_msgs/msg
[2] http://www.ros.org/reps/rep-0117.html

1 Like
2

I think the best way to go is to create a new message, where you include
the existing sensor_msgs/Range and add the missing fields.
Extending the current sensor_msgs/Range is not a good idea because it
would change the message checksum and all hell would break loose for those
already using it.

3

Thanks for the feedback, Procopio. Someone here at ROSCon mentioned this would likely be a problem too but I wasn’t sure how worried the community was about it. I’ll make the pull request.

4

Hi ,
just to comment that some radars provide, for each target detected, the Doppler velocity as a raw measurement made directly by the device. So it would be important to differentiate “range_rate” which, as JWhitleyAStuff said, the polar longitudinal velocity of tracks, from the “doppler_velocity” , which is also a polar longitudinal velocity, but issued from a wave signal processing step, and not issued from an object tracking process.
From the robotics perspective, doppler velocity is a raw measurement, like range.
best,
andreu

5

Thanks to everyone for the feedback. I think it’s unavoidable to change sensor_msgs/Range in, at least a minimalistic way - e.g. adding an enum value to radiation_type for RADIO. I’m going to go ahead and make the pull request and we can discuss the naming and architectural semantics there.

6

@JWhitleyWork Thanks for starting the thread and also opening the PR.

Now that common_msgs is relatively mature we generally want to make sure that messages are already in use and have been tested, instead of developing them in the abstract here. There’s some notes on contributing on the wiki page

We generally want things to have been validated by real use in the field before merging them into common_messages so that we can be confident that they are useful. Sometimes new messages here will also be a merge of two or more messages to standardize. Such as here for the BatteryState message.

There may be several classes of Radar returns that would be good to clarify/separate. There are potentially low level interfaces (range, intensity, velocity) as well as high level interfaces (object position, velocity, and scale). Surveying the field of sensors and understanding which ones can be covered by any given interface would be valuable in this process. And I’m sure that there are users with radar messages already that would be great to get their feedback and look for an already tested version of a radar message.

7

A good amount of people seemed to be interested in these messages. Just a note that they have now moved from https://github.com/astuff/platform_automation_msgs to https://github.com/astuff/astuff_sensor_msgs. All packages under these repos just got an update and have been released to ShadowFixed.

8

They are now available in the ROS official repos. You can sudo apt install ros-$ROS_DISTRO-radar-msgs from Ubuntu or Debian.

1 Like