Howdy yal, its your Friendly Neighborhood Navigator here!
REP 2003
I wanted to let you know about a new ROS REP which was accepted as a draft at the last TSC meeting and is now published for your perusal.
REP 2003 establishes the standard QoS settings to use for raw sensor data and map representations to be used within a robotic system. There has been historically issues with sensor processing pipelines, map subscriptions, and so on in ROS 2 having data not process due to incompatible QoS settings.
This REP seeks to establish these profiles to use such that it takes the guess work out of some portions of the system needed to interface with open-source or proprietary solutions. These standards are based on strong historical heritage even from ROS (1) in how folks handled their topics.
Maps should be served and received using a reliable, transient-local QoS. No depth is specified and is up to a user’s application
Sensor data from a driver should be provided using the SystemDefaultsQoS (reliable, volatile) while its consumers should be using SensorDataQoS to allow for unreliable transmission of sensor data to its first processing stage.
Note that the map standard is the same as in ROS 1 using a latched topic. Also note that the sensor data QoS only applies to raw data coming from a sensor. Once that data has been passed into the system, the QoS profile may vary between different stages in the processing pipeline.
What do you think?
We’re looking for feedback over the coming months while this REP settles into the mainstream. This is generally describing what is already commonly done, but we’d love your feedback and see where we can tweak or add to this standard for full acceptance as an REP. This REP is already at work within Nav2, SLAM and localization providers, and the main open-source sensor processing pipelines.
A couple of areas already brought up:
Specifying the QoS for sensor data publishers in the standard, not just SystemDefaultsQoS which could vary by RMW provider
Include specifications on actuation outputs (i.e. cmd_vel)
We’ll be leaving this thread open for the coming months, so if you have thoughts, please let them be known! We’ll work to rectify them for going from an accepted draft to a published full REP.
Uh, I can’t wrap my head around this. What is a sensor driver, what is first processing stage?
Does it dictate that the UDP stream of binary packets coming out of a lidar or GigE camera should be somehow converted to a DDS-compatible reliable stream?
Or, sometimes, there is a driver that decodes the binary stream to a GStreamer object and the ROS driver just uses GStreamer to access the data. What goes where in this case?
What is raw data? Is it the proprietary binary stream coming out of the sensor? Or is it this stream decoded to a Bayer RGGB with some metadata around?
A ROS driver, the thing connecting to a sensor and providing sensor data out (i.e. PointCloud2ImageImu and so on). The standard thing when we talk about “drivers” in ROS-world.
Anything after the raw data, like a multi-stage process for refining images or pointclouds for useful results.
@audrow could chime in, but I don’t think there should be any impact. The type adaptation work is how the data types are being manipulated before and after transport. The QoS policies that this REP regulates are the policies of the transport itself. You can use any QoS policy with type adaptations - so setting policies for what QoS you should use in a couple of common but narrow situations won’t interfere.
Sensors are real-time inputs that will consume compute and resources regardless of what QOS settings you choose. Is “reliable” the right setting?
When a system cannot keep up with the incoming sensor data, it has to drop somewhere. Eventually it will drop in the sensor driver as it will run out of memory as older sensor captures are stuck in queue on retries. Is the goal of the REP to prescribe the driver make this decision instead of the application?
This was a point of discussion in the REP thread. Originally, I had this as using the SensorDataQoS profile which is unreliable transmission for both pub and sub. It was pointed out to me that as long as the Durability is volatile, the publisher can be marked as reliable and the subscriber can be marked as best-effort so that the subscription can drop the data.
But what benefit is it having the publisher as reliable. A reliable publisher takes more resources than a best-efforts publisher. And if there is any bottleneck on the publisher side, it will queue up updates unnecessarily, I think.
It allows for more flexibility. Looking at the compatibility chart, you can see that if published reliable, both reliable and best-effort can subscribe to it. If best-effort published, only best-effort can subscribe to it.
With that said, perhaps there are more substantive drawbacks to that flexibility not worthy of the trade-off. I’m not opposed to reopening that as part of the full REP discussion. I’d like to pull @marguedas@clalancette in from that discussion in the REP.
I learned this the hard way: if your camera driver publishes with SensorDataQoS (sounds like a logical choice, no?) and you store it in a rosbag, you will have a headache when later playing back the image stream to e.g. rviz because of QoS incompatibility. See this issue here.