Radar Messages Standard

Next Generation ROS
1

Hi all, your friendly neighborhood navigation guru here.

As part of work in the up and coming navigation2 stack with new fancy features, we’re looking to add dynamic obstacle tracking and planning support. By looking I mean implementing, right now :slight_smile: We have some dedicated and interested parties involved and I’m sure we’ll have some really nice results to share.

Along that thinking, we have decided to start with RADARs. We have done this because we have a radar manufacturer (@aaron_Fulton from radar iq) actively helping us and because for most robots that don’t already have a GPU on-board, a radar is the most realistic sensor to get dynamic tracking information. (Pick either a $400 TX2 or a $150 RADAR with no extra computer/devops work… choice for me is simple)

We ran into the issue early of not having a standard set of RADAR messages for ROS. After consulting with Aaron, several members of the navigation working group, and @JWhitleyWork, we have created the first draft of standard messages for Radars in ROS.

Right now is the community soaking period at which we would like community feedback about these messages before they’re cemented for all time (or until reasonable to update them). We have 3 messages to propose currently:

  • RadarPoint, a single radar return (ex. single azimuth, elevation, intensity, etc).
  • RadarDetection, a radar detection from a set of radar returns by whatever vendor-specific means (ex. blob detection)
  • Radartrack, a track of the detections smoothed by whatever vendor-specific means (ex. EKF)

And their accompanying StampedArray messages.

The PRs for each message are:

The main repo is at ros-perception/radar_msgs.

In each message PR, there is a survey we did of all radar ROS drivers and uses we could find (several dozen) and a justification for our message to make sure that it A) complies with all or most radar packages uses B) fits the intent and content of the message format and C) follows best conventions.

We would like to open up a period for community feedback before these PRs land and these become a new standard interface. In the past, efforts to standardize radar_msgs have failed due to lack of community feedback. We’re lucky enough now to have 2 radar users/manufacturers working with us on it and a working group of people to give feedback (and now the larger community).

Over the next 2 weeks, please give any feedback on these messages. Once they are adopted, the plan will be to submit issue tickets in the repositories surveyed to migrate to these messages and potentially migrate a few of them ourselves.

Happy navigating,

Steve

9 Likes
2

@Ian_Colwell - AS might be interested in this.

1 Like
3

I’d also like AS to respond to my request (https://github.com/astuff/astuff_sensor_msgs/issues/54) to yield the name radar_msgs since it isn’t the result of surveying across multiple vendors. I’d appreciate if you could rename so that the standard definition can have the base name. I’ll help port to the new messages if you do so :heart:.

4

I wish I could but I’m not with AS anymore (I’m the Software Architect for The Autoware Foundation now). You’ll have to get one of the guys from AS to do it. Might want to shoot them an email. I don’t know their new support email since they changed over to Hexagon but their general email is info.as.ap@hexagon.com.

5

Glad to see someone standardizing radar stuff for ROS.

Is the coordinate system for radars in ROS defined somewhere?
For example should my TFs be with the x-axis pointing outward like a lidar, or with the z-axis like a camera?

If so can you link to it in the message definitions?

6

Great question, that wasn’t in the scope of this PR but I don’t see why we couldn’t make these conventions too, though it would require an REP and that’s a long process. Because the messages have a frame_id and the data is relative to it, for the purposes of the messages it doesn’t matter. I think Z forward X up would be reasonable though. I think we should consult radar manufacturers and see what they typically use, @aaron_Fulton?

7

That’s exactly what the standard needs to define. If publish with Z forward and I interpret it as X forward it will look like a car straight ahead is falling from the sky. Unless there’s a very strong reason we shouldn’t diverge from REP 103’s standard. We’ll if you diverge from REP 103 it needs to be clearly documented as that’s the expected default on ROS systems.

3 Likes
8

Does REP 103 cover sensors? Sweet, yes, let us declare that Radars will also be REP 103 compliant

* wipes hands * well that was easy.

Also, thank you for critically reviewing the messages, I really appreciate some lively discussion.

2 Likes
9

Out of curiosity: has it been considered to add those messages to the sensor_msgs package? Is something speaking against this?

This would be the same as with the various laserscan packages. And would bring the additional benefit that there is no package name clash anymore :wink:

1 Like
10

Thanks for the notification @JWhitleyWork!
@smac, we’ll look into this and someone will respond to the github issue soon.

Happy to see radar msg standardization!

1 Like
11

Another great question. Because this is new, having a separate package is useful so that over the next couple of distributions if we need to do some tweaks, its more possible. In steady state, I would have no objections with its inclusion into the sensor standard interfaces.

1 Like
12

Once it’s stabilized contributing it to common_interfaces would make sense. We like to have working examples and proven functionality before we promote content to be considered part of the common_interfaces.

Documentation from common_msgs

https://wiki.ros.org/common_msgs#Guidelines_for_submitting_to_common_msgs

And I’ve opened a PR to add that to common_interfaces documentation too:

We can probably formalize this more with the new Quality Categories and stability requirements in REP 2004

13

Makes sense. Wasn’t aware of the already existing guidelines. Thanks for the clarification!

14

Hello,

I am very interested with experimenting radar hardware on small robots.
What is the shortest route to hardware that we can currently get to be able to slam / navigate with ros?

15

That’s a bit out of scope of this discussion.

16

Reviving this conversation, after much long discussion we’re narrowing into the message format for the RadarTracks messages. If you’re a stakeholder or radar user in ROS, please take a look at this PR and add any additional comments or specific recommendations. If you approve, give it a :heavy_check_mark: review.

1 Like