REP 2003: Sensor Data and Map QoS Settings

rep-2003.rst

@@ -0,0 +1,76 @@
+REP: 2003
+Title:  Sensor Data and Map QoS Settings
+Author: Steve Macenski <stevenmacenski at gmail.com>
+Status: Draft
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 08-Nov-2019
+ROS-Version: Dashing
+Post-History: 08-Nov-2019
+
+Abstract
+========
+
+This REP covers the standards surrounding Quality of Service (QoS) settings for common needs in ROS2.
+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 ROS2 interoperability.
+
+Specification
+=============
+
+Map Quality of Service
+----------------------
+
+Map providers such as map servers and SLAM implementations are expected to provide all maps over a reliable local-transient 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 local-transient 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.
+
+Sensor Driver Quality of Service
+--------------------------------
+
+Sensor data provided by a sensor driver from a camera, inertial measurement unit, laser scanner, GPS, depth, or range finder are expected to be provided over a `SensorDataQoS` quality of service as provided by the implemented ROS2 version API.
+This is to allow for unreliable transmission of sensor data directly from source to its first processing stage(s).
+These processing stage(s) are also expected to receive a sensor reading using the SensorDataQoS provided QoS profile implemented by the ROS2 version API.
+
+This specification does not enforce QoS settings for sensor data transmitted or received by stage(s) after the sensor driver.
+
+Rationale
+=========
+
+Why Specify QoS Settings
+------------------------
+
+Unlike ROS1, ROS2's QoS settings chosen by an application can affect the ability for data to be transmitted from a publisher to a subscriber.
+There exists several combinations of QoS settings 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.
+
+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.
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
+
+..
+   Local Variables:
+   mode: indented-text
+   indent-tabs-mode: nil
+   sentence-end-double-space: t
+   fill-column: 70
+   coding: utf-8
+   End: