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.

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

Adding deadline, liveliness and other QoS to ROS 2 #572

dejanpan opened this Issue Oct 17, 2018 · 0 comments


None yet
2 participants

dejanpan commented Oct 17, 2018

This issue is to start discussing adding of additional QoS to ROS 2. In particular the first two QoS that deem to be really necessary are:

  1. Deadline which is needed for when data is needed at constant periodicity (e.g. vehicle data for controller at exactly 1kHz).
  2. Liveliness which specifies and configures the mechanism that allows DDSDataReader entities to detect when DDSDataWriter entities become disconnected or "dead. This QoS setting is needed for a heartbeat feature in managed nodes.

General approach

As ROS 2 is C++11/14 it seems natural to implement advanced features alongside the DDS C++11 API described here. While this API is AFAIK not an official DDS standard, or at least I could not find it on the OMG page) Connext Pro and OpenSplice use this exact API.

As most functionality is implemented around the wait-set concept it makes sense to do the same in ROS 2 as the existing callback-based API which is very similar to ROS 1 is not modified.

DDS C++11/14 concept summary:

Everything in DDS is Event-based. Events in DDS are called Conditions.
There are several kinds of Conditions:

Read Conditions

Everything that has to do with the state of a sample or instance (keyed group).
A read condition is triggered when a sample with the attached (Data State)[] is received or an existing sample changes to this data state.

Status Condition

Everything that is related to events not to a state of a sample.
New data reader/writer detected.
Incompatible QOS detected.
Deadline missed.
DataWriter died.

List of possible status:

Condition management:

The user needs to be able to check if a condition did happen. There are two ways to do this:

  • Waitsets: The recommended way by RTI.
  • Callbacks: Only recommended for special ultra-low latency applications (can be dangerous) (by RTI)[]. Also, the callback based approach is much harder to use in my experience.

So rclcpp should implement the waitset based approach:

QOS Configuration

QOS settings must also be configured, which is the easier thing to do.




Utility functions

Some utility functions like asserting liveliness and translating instance handles to keys and via versa must also be provided on a DataWriter and DataReader level.

@dirk-thomas dirk-thomas referenced this issue Oct 23, 2018


ROS 2 Crystal Clemmys #529

6 of 29 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment