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.