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 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
The PRs for each message are:
- Point https://github.com/ros-perception/radar_msgs/pull/1
- Detection https://github.com/ros-perception/radar_msgs/pull/2
- Track https://github.com/ros-perception/radar_msgs/pull/3
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.