From a1ecf80e8a72663b9152c213b4f7e554b5164f40 Mon Sep 17 00:00:00 2001 From: stevemacenski Date: Wed, 13 Nov 2019 12:33:02 -0800 Subject: [PATCH 01/16] adding rep-2003: Sensor Data and Map QoS Settings --- rep-2003.rst | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+) create mode 100644 rep-2003.rst diff --git a/rep-2003.rst b/rep-2003.rst new file mode 100644 index 000000000..687bfd1f8 --- /dev/null +++ b/rep-2003.rst @@ -0,0 +1,65 @@ +REP: 2003 +Title: Sensor Data and Map QoS Settings +Author: Steve Macenski +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 as 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 variably depth. + +This specification does not enforce any particular map representation but rather applies for all shared map representations including but not limited to occupancy grids, feature maps, or 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 effect 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 exists 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. + + +Backwards 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: From 4610c29d9954eebfe5525c7ea4840a33fadfc8f4 Mon Sep 17 00:00:00 2001 From: stevemacenski Date: Wed, 13 Nov 2019 14:07:49 -0800 Subject: [PATCH 02/16] one sentence per line for REP-2003 --- rep-2003.rst | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/rep-2003.rst b/rep-2003.rst index 687bfd1f8..5e54aeda5 100644 --- a/rep-2003.rst +++ b/rep-2003.rst @@ -11,7 +11,8 @@ 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. +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 ============= @@ -19,14 +20,19 @@ Specification Map Quality of Service ---------------------- -Map providers such as map servers and SLAM implementations are expected to provide all maps as 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 variably depth. +Map providers such as map servers and SLAM implementations are expected to provide all maps as 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 variably depth. This specification does not enforce any particular map representation but rather applies for all shared map representations including but not limited to occupancy grids, feature maps, or 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. +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. @@ -36,18 +42,23 @@ Rationale Why Specify QoS Settings ------------------------ -Unlike ROS1, ROS2's QoS settings chosen by an application can effect 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. +Unlike ROS1, ROS2's QoS settings chosen by an application can effect 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 exists 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. +There exists 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. Backwards 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. +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 ========= From 63e385dc1a253d242ca461dba79255054ed63479 Mon Sep 17 00:00:00 2001 From: Steven Macenski Date: Thu, 14 Nov 2019 08:40:19 -0800 Subject: [PATCH 03/16] Update rep-2003.rst Co-Authored-By: G.A. vd. Hoorn --- rep-2003.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rep-2003.rst b/rep-2003.rst index 5e54aeda5..ef0c88747 100644 --- a/rep-2003.rst +++ b/rep-2003.rst @@ -20,7 +20,7 @@ Specification Map Quality of Service ---------------------- -Map providers such as map servers and SLAM implementations are expected to provide all maps as over a reliable local-transient topic. +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 variably depth. From 7f1e099115e4ce9e0f04848465895de8073fb373 Mon Sep 17 00:00:00 2001 From: Steven Macenski Date: Thu, 14 Nov 2019 08:40:27 -0800 Subject: [PATCH 04/16] Update rep-2003.rst Co-Authored-By: G.A. vd. Hoorn --- rep-2003.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rep-2003.rst b/rep-2003.rst index ef0c88747..4ae105ba3 100644 --- a/rep-2003.rst +++ b/rep-2003.rst @@ -23,7 +23,7 @@ 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 variably depth. +Map clients are also expected to receive maps over a reliable local-transient topic with variable depth. This specification does not enforce any particular map representation but rather applies for all shared map representations including but not limited to occupancy grids, feature maps, or dense representations. From c9b95dbb81bf0ac956113c5435f2509dbe09a83f Mon Sep 17 00:00:00 2001 From: Steven Macenski Date: Thu, 14 Nov 2019 08:40:35 -0800 Subject: [PATCH 05/16] Update rep-2003.rst Co-Authored-By: G.A. vd. Hoorn --- rep-2003.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rep-2003.rst b/rep-2003.rst index 4ae105ba3..1be3ea657 100644 --- a/rep-2003.rst +++ b/rep-2003.rst @@ -25,7 +25,7 @@ This is to allow for reliable transmission of map data and provide the map infor 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 enforce any particular map representation but rather applies for all shared map representations including but not limited to occupancy grids, feature maps, or dense representations. +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 -------------------------------- From 28e2d8d1a35e649666719d482bfc4a8849d4340c Mon Sep 17 00:00:00 2001 From: Steven Macenski Date: Thu, 14 Nov 2019 08:40:48 -0800 Subject: [PATCH 06/16] Update rep-2003.rst Co-Authored-By: G.A. vd. Hoorn --- rep-2003.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rep-2003.rst b/rep-2003.rst index 1be3ea657..15809ce98 100644 --- a/rep-2003.rst +++ b/rep-2003.rst @@ -30,7 +30,7 @@ This specification does not prescribe any particular map representation but rath 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. +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. From 01fbe111f963abc7c447e4ffc150bb5dc890f619 Mon Sep 17 00:00:00 2001 From: Steven Macenski Date: Thu, 14 Nov 2019 08:40:56 -0800 Subject: [PATCH 07/16] Update rep-2003.rst Co-Authored-By: G.A. vd. Hoorn --- rep-2003.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rep-2003.rst b/rep-2003.rst index 15809ce98..54610e8ee 100644 --- a/rep-2003.rst +++ b/rep-2003.rst @@ -42,7 +42,7 @@ Rationale Why Specify QoS Settings ------------------------ -Unlike ROS1, ROS2's QoS settings chosen by an application can effect the ability for data to be transmitted from a publisher to a subscriber. +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. From 9430752068f01a0a9d276fdbe7bacfc0b6bb51e5 Mon Sep 17 00:00:00 2001 From: Steven Macenski Date: Thu, 14 Nov 2019 08:41:04 -0800 Subject: [PATCH 08/16] Update rep-2003.rst Co-Authored-By: G.A. vd. Hoorn --- rep-2003.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rep-2003.rst b/rep-2003.rst index 54610e8ee..fb3ce05d9 100644 --- a/rep-2003.rst +++ b/rep-2003.rst @@ -49,7 +49,7 @@ By specifying QoS settings for common interfaces, the aim is to ensure all senso Why Not Specify Later Stage Sensor QoS Settings ----------------------------------------------- -There exists numerous requirements and uses of pre-processed sensor data. +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. From 5a8a322e4f88f5e06aed91a21081075bed936fa8 Mon Sep 17 00:00:00 2001 From: Steven Macenski Date: Thu, 14 Nov 2019 08:41:15 -0800 Subject: [PATCH 09/16] Update rep-2003.rst Co-Authored-By: G.A. vd. Hoorn --- rep-2003.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rep-2003.rst b/rep-2003.rst index fb3ce05d9..b6e4aee27 100644 --- a/rep-2003.rst +++ b/rep-2003.rst @@ -53,7 +53,7 @@ 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. -Backwards Compatibility +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. From d042ae6a8bc338d47bddb08fcc4518869b46290f Mon Sep 17 00:00:00 2001 From: stevemacenski Date: Thu, 14 Nov 2019 09:05:02 -0800 Subject: [PATCH 10/16] changing transient-local from local-transient --- rep-2003.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rep-2003.rst b/rep-2003.rst index 5e54aeda5..683f156cb 100644 --- a/rep-2003.rst +++ b/rep-2003.rst @@ -20,10 +20,10 @@ Specification Map Quality of Service ---------------------- -Map providers such as map servers and SLAM implementations are expected to provide all maps as over a reliable local-transient topic. +Map providers such as map servers and SLAM implementations are expected to provide all maps as 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 local-transient topic with variably depth. +Map clients are also expected to receive maps over a reliable transient-local topic with variably depth. This specification does not enforce any particular map representation but rather applies for all shared map representations including but not limited to occupancy grids, feature maps, or dense representations. From d96957ed4ca8a9647e63241cfc7bf2e38f3a7d84 Mon Sep 17 00:00:00 2001 From: Steve Macenski Date: Tue, 29 Nov 2022 11:48:03 -0800 Subject: [PATCH 11/16] Update rep-2003.rst Co-authored-by: Chris Lalancette --- rep-2003.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rep-2003.rst b/rep-2003.rst index 79dd36271..cd1c3ab87 100644 --- a/rep-2003.rst +++ b/rep-2003.rst @@ -11,7 +11,7 @@ Post-History: 08-Nov-2019 Abstract ======== -This REP covers the standards surrounding Quality of Service (QoS) settings for common needs in ROS2. +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 ROS2 interoperability. Specification From 69e4a1c6052d0387ab102d675f7129239b9c2f45 Mon Sep 17 00:00:00 2001 From: Steve Macenski Date: Tue, 29 Nov 2022 11:48:11 -0800 Subject: [PATCH 12/16] Update rep-2003.rst Co-authored-by: Chris Lalancette --- rep-2003.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rep-2003.rst b/rep-2003.rst index cd1c3ab87..069257dda 100644 --- a/rep-2003.rst +++ b/rep-2003.rst @@ -12,7 +12,7 @@ Abstract ======== 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 ROS2 interoperability. +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. Specification ============= From 5edfa14f64d92b8bc747787ffe154014858429fa Mon Sep 17 00:00:00 2001 From: Steve Macenski Date: Tue, 29 Nov 2022 11:48:18 -0800 Subject: [PATCH 13/16] Update rep-2003.rst Co-authored-by: Chris Lalancette --- rep-2003.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rep-2003.rst b/rep-2003.rst index 069257dda..ff5dd1f8c 100644 --- a/rep-2003.rst +++ b/rep-2003.rst @@ -42,7 +42,7 @@ 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. +Unlike ROS1, 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 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. From 36a48d336d089c59c92b2fc8f3d12e8a6a9bfef5 Mon Sep 17 00:00:00 2001 From: stevemacenski Date: Wed, 30 Nov 2022 12:59:06 -0800 Subject: [PATCH 14/16] review changes --- rep-2003.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/rep-2003.rst b/rep-2003.rst index ff5dd1f8c..33419a6fd 100644 --- a/rep-2003.rst +++ b/rep-2003.rst @@ -5,8 +5,7 @@ Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 08-Nov-2019 -ROS-Version: Dashing -Post-History: 08-Nov-2019 +Post-History: 30-Nov-2022 Abstract ======== @@ -30,9 +29,9 @@ This specification does not prescribe any particular map representation but rath 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. +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). -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. @@ -42,9 +41,10 @@ Rationale Why Specify QoS Settings ------------------------ -Unlike ROS1, 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 exists several combinations of QoS settings that will not transmit data from one node to another even while composed in a single process. +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. +The 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 ----------------------------------------------- From ab0fb054268f497f27c265f37a8caae6d7ae852f Mon Sep 17 00:00:00 2001 From: stevemacenski Date: Fri, 10 Feb 2023 16:25:27 -0800 Subject: [PATCH 15/16] adding based on review comments --- rep-0145.rst | 40 ++++++++++++++++++++++++++++++++-------- 1 file changed, 32 insertions(+), 8 deletions(-) diff --git a/rep-0145.rst b/rep-0145.rst index bab1e1c0a..217e90211 100644 --- a/rep-0145.rst +++ b/rep-0145.rst @@ -53,7 +53,7 @@ Data Reporting * All data from a sensor should be published with respect to a single consistent sensor frame. If any data is reported in an inconsistent frame of reference relative to the other data, the driver must transform it into the sensor frame before publishing. -* Otherwise, all data should be published by the driver as it is reported by the device. Any subsequent modifications to the data (e.g. filtering, transformations) should be delegated to a downstream consumer of the data [3]_. +* Otherwise, all data should be published by the driver as it is reported by the device. Any subsequent modifications apart from vendor-specific SDK functionality to the data (e.g. filtering, transformations) should be delegated to a downstream consumer of the data [3]_. * A prominent note should be made in the driver documentation regarding any internal data manipulation that does not comply with the requirements in this document. @@ -93,26 +93,50 @@ Topics The following topics are expected to be common to many devices - an IMU device driver is expected to publish at least one. Note that some of these topics may be also published by support libraries, rather than the base driver implementation. All message types below are supplemented with a std_msgs/Header, containing time and coordinate frame information. +* `imu/data` (sensor_msgs/Imu) -* `imu/data_raw` (sensor_msgs/Imu) + - General consolidated sensor data containing `AngularVelocity`, `Attitude`, and `LinearAcceleration` published at the natural frequency of attitude estimation. - - Sensor output grouping accelerometer (`linear_acceleration`) and gyroscope (`angular_velocity`) data. +* `imu/angular_velocity` (sensor_msgs/AngularVelocity) -* `imu/data` (sensor_msgs/Imu) + - Sensor output containing gyroscope data. + +* `imu/attitude` (sensor_msgs/Attitude) + + - Sensor output containing information about the attitude estimation. - - Same as `imu/data_raw`, with an included quaternion orientation estimate (`orientation`). +* `imu/linear_acceleration` (sensor_msgs/LinearAcceleration) + + - The sensor output of the measured linear acceleration. * `imu/mag` (sensor_msgs/MagneticField) - Sensor output containing magnetometer data. - -All message types provide a covariance matrix (see REP 103 [1]_) alongside the data field (`*_covariance`). If the data's covariance is unknown, all elements of the covariance matrix should be set to 0, unless overridden by a parameter. If a data field is unreported, the first element (`0`) of the covariance matrix should be set to `-1`. +All message types provide a covariance matrix (see REP 103 [1]_) alongside the data field (`*_covariance`). If the data's covariance is unknown, all elements of the covariance matrix should be set to 0, unless overridden by a parameter. If a data field is unreported, the first element (`0`) of the covariance matrix should be set to `NaN`. +The timestamp for these messages should reflect the best estimate of when the observation was made. +It is expected that downstream users may want to use data from multiple of these topics. Namespacing ''''''''''' -By convention, IMU output topics are pushed down to a local namespace. The primary source of IMU data for a system is published in the `imu` namespace. Additional sources, such as secondary IMUs or unprocessed raw data should be published in alternative `imu_...` local namespaces. IMU driver implementations should take care to allow convenient remapping of the local namespace through a single remap argument (e.g. imu:=imu_raw), rather than separate remap calls for each topic. +By convention, IMU output topics are pushed down to a local namespace. The primary source of IMU data for a system is published in the `imu` namespace. Additional sources, such as secondary IMUs or unprocessed raw data should be published in alternative `imu_...` local namespaces. IMU driver implementations should take care to allow convenient remapping of the local namespace through a single remap argument (e.g. imu:=imu_raw), rather than separate remap calls for each topic. The following are some standard namespaces to represent certain types of data: + +* `imu_raw` + + - Containing topics of raw data + +* `imu_unbiased` + + - Containing topics of unbiased data + +* `imu_biased` + + - Containing topics of biased data + +* `imu_compensated` + + - Containing topics of gravity compensated data Common Parameters ----------------- From a7e5e6a337a859f8ca789e5aa65067b508ef466d Mon Sep 17 00:00:00 2001 From: stevemacenski Date: Fri, 10 Feb 2023 16:28:33 -0800 Subject: [PATCH 16/16] remove REP 2003 from PR --- rep-2003.rst | 76 ---------------------------------------------------- 1 file changed, 76 deletions(-) delete mode 100644 rep-2003.rst diff --git a/rep-2003.rst b/rep-2003.rst deleted file mode 100644 index 33419a6fd..000000000 --- a/rep-2003.rst +++ /dev/null @@ -1,76 +0,0 @@ -REP: 2003 -Title: Sensor Data and Map QoS Settings -Author: Steve Macenski -Status: Draft -Type: Standards Track -Content-Type: text/x-rst -Created: 08-Nov-2019 -Post-History: 30-Nov-2022 - -Abstract -======== - -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. - -Specification -============= - -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. - -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. - -Rationale -========= - -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. -The 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. - -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: