[REP Index] [REP Source]

Title:Sensor Data and Map QoS Settings
Author:Steve Macenski <stevenmacenski at gmail.com>
Type:Standards Track


This REP covers the standards surrounding Quality of Service (QoS) settings for common needs in ROS 2. This includes sensor drivers and map representations to standardize interfaces of not only message types outlined by REPs such as REP 118, 138, and 145, but also QoS to ensure ROS 2 interoperability.


Map Quality of Service

Map providers such as map servers and SLAM implementations are expected to provide all maps over a reliable transient-local topic. This is to allow for reliable transmission of map data and provide the map information to any new map clients without delay. The depth of the transient-local storage depth is left to the designer, however a single map depth is a reasonable choice for static or globally-updated dynamic map serving applications. Map clients are also expected to receive maps over a reliable transient-local topic with variable depth.

This specification does not prescribe any particular map representation but rather applies to all shared map representations, including but not limited to: occupancy grids, feature maps and dense representations.

This specification does not enforce QoS settings for map-like data for collision avoidance or planning, such as cost grids, which may have their own unique operating context and needs. This specification applies only to maps and environmental models, both complete and with partial updates.

Sensor Driver Quality of Service

Sensor data provided by a sensor driver from a camera, inertial measurement unit, laser scanner, GPS, depth, range finder, or other sensors are expected to be provided over a SystemDefaultsQoS quality of service as provided by the implemented ROS 2 version API. Consumers of sensor data are to use SensorDataQoS quality of service as provided by the implemented ROS 2 version API. This is to allow for unreliable transmission of sensor data directly from source to its first processing stage(s).

This specification does not enforce QoS settings for sensor data transmitted or received by stage(s) after the sensor driver.


Why Specify QoS Settings

Unlike ROS 1, ROS 2's QoS settings chosen by an application can affect the ability for data to be transmitted from a publisher to a subscriber. There may exist publisher and subscriber QoS combinations that will not transmit data from one node to another, even while composed in a single process. By specifying QoS settings for common interfaces, the aim is to ensure all sensor data and map sources can be interchangable with each other at run-time. This resolves subtle user issues of new sensor and map data sources not being communicated due to QoS incompatibilities leading some to believe a driver or package is not functioning.

Why Not Specify Later Stage Sensor QoS Settings

There exist numerous requirements and uses of pre-processed sensor data. It would be presumptuous of this REP to equally treat data transmissions in safety critical or best-effort pipelines.

Backward Compatibility

It is up to the maintainer of a sensor driver or map source provider to determine if the provider should be updated to follow this REP. If a maintainer chooses to update, the current usage should at minimum follow a tick tock pattern where the old usage is deprecated and warns the user, followed by removal of the old usage. The maintainer may choose to support both standard and custom usage, as well as extend this usage or implement this usage partially depending on the specifics of the interface.