Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

REP 2003: Sensor Data and Map QoS Settings #212

Merged
merged 18 commits into from
Jan 9, 2024
Merged

REP 2003: Sensor Data and Map QoS Settings #212

Changes from all commits
Commits
Show all changes
18 commits
Select commit Hold shift + click to select a range
a1ecf80
adding rep-2003: Sensor Data and Map QoS Settings
SteveMacenski Nov 13, 2019
4610c29
one sentence per line for REP-2003
SteveMacenski Nov 13, 2019
63e385d
Update rep-2003.rst
SteveMacenski Nov 14, 2019
7f1e099
Update rep-2003.rst
SteveMacenski Nov 14, 2019
c9b95db
Update rep-2003.rst
SteveMacenski Nov 14, 2019
28e2d8d
Update rep-2003.rst
SteveMacenski Nov 14, 2019
01fbe11
Update rep-2003.rst
SteveMacenski Nov 14, 2019
9430752
Update rep-2003.rst
SteveMacenski Nov 14, 2019
5a8a322
Update rep-2003.rst
SteveMacenski Nov 14, 2019
d042ae6
changing transient-local from local-transient
SteveMacenski Nov 14, 2019
7678158
fix merge
SteveMacenski Nov 14, 2019
d96957e
Update rep-2003.rst
SteveMacenski Nov 29, 2022
69e4a1c
Update rep-2003.rst
SteveMacenski Nov 29, 2022
5edfa14
Update rep-2003.rst
SteveMacenski Nov 29, 2022
36a48d3
review changes
SteveMacenski Nov 30, 2022
9945ca4
Fix formatting issue with extra line
SteveMacenski Nov 13, 2023
d9c39d1
Update rep-2003.rst
SteveMacenski Nov 14, 2023
1c27230
Update rep-2003.rst
SteveMacenski Nov 27, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
77 changes: 77 additions & 0 deletions rep-2003.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,77 @@
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
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
mjcarroll marked this conversation as resolved.
Show resolved Hide resolved
----------------------

Map providers such as map servers and SLAM implementations are expected to provide all maps over a reliable transient-local topic.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you need to discuss map updates here, if nothing else than to draw a box around the GCR formats you discuss here. You say "all maps" but that comment seems to point to just some maps.

I understand that the representation is not part of this discussion, but there are separate message based approaches (namely map_msgs::msg::OccupancyGridUpdate) for handling differently aged subscriptions. The last time I looked at this, the state of the RCL/DDS cluster was such that the onNewSubscription functionality in the TODO here was not (yet?) implemented, although that may have changed.

The ROS 1 mechanism relied on being able to send a full map message to only new subscriptions, thus ensuring that you could subscribe ONLY to the full message topic and get the most up to date map. By saying that all maps should be transient local, are you also ensuring that all subscribers will always get a full update any time the data changes?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The last time I looked at this, the state of the RCL/DDS cluster was such that the onNewSubscription functionality in the TODO here was not (yet?) implemented, although that may have changed.

As of Iron, the core supports this with the use of "Matched" callbacks. See http://docs.ros.org/en/iron/Releases/Release-Iron-Irwini.html#matched-events .

Copy link
Contributor Author

@SteveMacenski SteveMacenski Nov 14, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DLu costmaps are not maps, so the costmap update topics are out of scope since those are collision avoidance/planning models and not environmental models that this REP is covering. The text is pretty clear in line about the scope that this is covering. But this is a good clarification to make:

  • Explicitly restrict REP to environmental models, not to be confused with costmaps or other map-like structures for collision avoidance or C-space representation transportation

but also the OccGrid / Update topics have a stamped header, so it should not be challenging to disambiguate old updates to be disgarded. I still agree that Transient Local is the right answer even if we are using an update-structure. You wouldn't want (1) the main updated map to come in then start processing and wait on a polling basis for the update to come in, then (2) the algorithm could start planning with outdated data. Having it be event based on connection due to the QoS is still a preferable experience. There's certainly some technical decision making about how to handle the case, but this isn't a roadmap for map update schemes, this is a REP on the QoS to communicate them under.

Unless you disagree that updates should be also transient local, which we do today for for some time now, I think this REP does not require further updates on the topic. Though, some other documents about how to process the updates could be useful to provide a general roadmap for end-users, I don't disagree

If you think some clarify w.r.t. updates specifically as it applies to QoS, let me know what you're thinking is needed to clarify and I can make that happen.

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.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Am I understanding this correctly, that the publisher should use SystemDefaultsQoS and the subscriber SensorDataQoS? Why different QoS settings for those? Am I missing something?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO SystemDefaultsQoS is not safe to be used and it should be deprecated, rather than being encouraged in a REP.
Components should explictly declare their QoS and not rely on the underlying "system default" which are system specific and RMW specific

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the discussions above. This was a request from OSRF folks and I think its a sensible choice

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could call out what SystemDefaultsQoS means under the hood and I think that would be fine too (e.g. Volatile, Reliable, History depth of a user's choice).

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some sensor drivers may produce data only "on change" rather than at a fixed, usually fast, period.
these topics should use transient local reliable publication

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For example?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That doesn't seem like raw sensor feeds to me, but the output of a node that is doing some pre-processing (e.g. stage). The REP calls out that we only consider raw sensor data and aren't covering between stages which might have other operating contexts. I think that should cover it unless there are actual "on change" raw sensor data inputs - which I can't think of an example of


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.
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.
SteveMacenski marked this conversation as resolved.
Show resolved Hide resolved

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.

SteveMacenski marked this conversation as resolved.
Show resolved Hide resolved
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:
Loading