Skip to main content

Chapter 6: Advanced ROS 2 Concepts

6.1 Lifecycle Nodes and State Management​

Traditional ROS 1 nodes typically start in an operational state and remain there until terminated. ROS 2 introduces lifecycle nodes, which provide a defined state machine for nodes, enabling more robust, predictable, and manageable applications, especially in critical systems.

Introduction to Managed Nodes​

A lifecycle node can transition between a set of predefined states and performs specific callbacks during these transitions. This allows for:

  • Ordered Startup/Shutdown: Ensuring dependencies are met before a node becomes active and resources are properly released during shutdown.
  • Error Recovery: Gracefully handling faults by transitioning to safe states.
  • System Predictability: Knowing the exact state of a node at any given time.

States (Unconfigured, Inactive, Active, Finalized)​

Lifecycle nodes typically move through the following states:

  • unconfigured: Initial state after creation. Node has been instantiated but not yet configured.
  • inactive: Node has been configured (e.g., loaded parameters, allocated resources) but is not yet processing data.
  • active: Node is fully operational, processing data, and interacting with the ROS 2 graph.
  • finalized: Terminal state after an orderly shutdown.

Transitions (Configure, Activate, Deactivate, Cleanup, Shutdown)​

Transitions are triggered by commands (e.g., ros2 lifecycle set <node_name> activate) and execute specific callback functions within the node:

  • on_configure: Called when transitioning from unconfigured to inactive.
  • on_activate: Called when transitioning from inactive to active.
  • on_deactivate: Called when transitioning from active to inactive.
  • on_cleanup: Called when transitioning from inactive to unconfigured.
  • on_shutdown: Called when the node is shutting down from any state to finalized.

Benefits for System Robustness​

Lifecycle nodes significantly enhance system robustness by:

  • Preventing race conditions during startup.
  • Allowing for controlled resource allocation and deallocation.
  • Facilitating fault detection and controlled recovery procedures.

6.2 Quality of Service (QoS) Settings​

Quality of Service (QoS) policies are a powerful feature in ROS 2 that allow developers to fine-tune the communication behavior between nodes. Since ROS 2 is built on DDS, it inherits DDS's rich set of QoS settings, which dictate how data is delivered, stored, and managed. This is crucial for matching communication needs to application requirements, especially for real-time or unreliable network scenarios.

Overview of QoS Policies​

Key QoS policies include:

  • reliability:
    • best_effort (default): Messages might be lost, but delivery is faster (e.g., sensor data).
    • reliable: Guarantees delivery, potentially at the cost of latency (e.g., critical commands).
  • durability:
    • volatile (default): Only new subscribers receive messages published after they subscribe.
    • transient_local: Publisher retains messages and sends them to new subscribers (e.g., configuration data).
  • history:
    • keep_last: Only the N most recent messages are stored.
    • keep_all: All messages are stored up to a certain limit.
  • depth: Used with keep_last to specify N (the number of messages to keep).
  • lifespan: Defines how long a message is valid.

Impact on Communication​

Properly configuring QoS can:

  • Improve communication performance by choosing less strict policies for non-critical data.
  • Enhance reliability for critical data by guaranteeing delivery.
  • Ensure data availability for late-joining subscribers.

Configuring QoS for Publishers and Subscribers​

QoS profiles can be set programmatically when creating publishers or subscribers. For example, a subscriber to a critical command topic might require reliable reliability, while a publisher of high-frequency sensor data might use best_effort.

Diagram: ROS 2 QoS Policies Overview​

Placeholder for ROS 2 QoS Policies Diagram

6.3 DDS Middleware Communication​

The Data Distribution Service (DDS) is the underlying communication middleware that powers ROS 2. It's an open standard developed by the Object Management Group (OMG) designed for real-time, high-performance, and scalable data exchange in distributed systems. Understanding DDS is key to fully grasping ROS 2's capabilities, especially its QoS policies and decentralized nature.

Deep Dive into DDS (Data Distribution Service)​

DDS provides a publish-subscribe communication model where data writers (publishers) send data and data readers (subscribers) receive it. Key characteristics of DDS include:

  • Discovery: Participants (applications) dynamically discover each other and available topics without a central broker.
  • Global Data Space: All data is accessible through a conceptual "global data space," even if physically distributed.
  • Type-Safety: Data types are strictly defined, ensuring consistent interpretation across participants.
  • Configurable QoS: As discussed, DDS offers extensive QoS policies to control communication behavior.

Underlying Communication Protocol​

DDS implementations (e.g., Fast RTPS, Cyclone DDS, RTI Connext) use a protocol called RTPS (Real-Time Publish-Subscribe) for wire-level interoperability. RTPS operates over various transports, most commonly UDP/IP multicast for discovery and unicast for data transfer.

Discovery, Data Transfer​

When a ROS 2 node starts, its DDS layer publishes information about its existence and the topics/services it offers. Other nodes' DDS layers subscribe to this discovery information. Once discovered, data communication directly between publishers and subscribers is established, bypassing any central server. This peer-to-peer communication is what gives ROS 2 its decentralized and efficient nature.

Diagram: DDS Communication Flow​

Placeholder for DDS Communication Flow Diagram

6.4 Connecting ROS 1 and ROS 2 Systems: The ROS 2 Bridge​

In many existing robotics applications, there's a significant investment in ROS 1 codebases. The ROS 2 Bridge (also known as ros1_bridge) provides a mechanism to facilitate communication and interoperability between ROS 1 and ROS 2 ecosystems, allowing developers to gradually migrate their systems or leverage existing ROS 1 components in a ROS 2 environment.

Motivation for Bridging​

  • Gradual Migration: Allows developers to port components incrementally without a complete rewrite.
  • Leverage Existing Code: Use mature ROS 1 drivers, algorithms, or tools that haven't yet been migrated to ROS 2.
  • Interoperability: Connect ROS 1 and ROS 2 robots or systems within the same network.

How the Bridge Works (Topic, Service Translation)​

The ROS 2 Bridge operates as a set of ROS 2 nodes (typically managed by a launch file) that act as translators. It subscribes to ROS 1 topics/services and publishes equivalent ROS 2 topics/services, and vice versa.

  • Topic Translation: Messages published on a ROS 1 topic are converted to their ROS 2 equivalents (if a mapping exists) and published on a corresponding ROS 2 topic.
  • Service Translation: A ROS 2 client can call a ROS 1 service via the bridge, and the response is translated back to ROS 2.

Configuration and Usage​

The bridge configuration often involves specifying which topics and services should be translated, and defining custom message conversions if standard mappings are insufficient. The ros1_bridge package provides executables and launch files to set up these translations.

6.5 Real-Time Constraints and Determinism​

Robotic systems often operate in environments where timely and predictable responses are critical. Real-time constraints refer to the deadlines within which computations must be completed. Determinism means that a system's behavior is predictable and repeatable given the same inputs. ROS 2 was designed with these considerations in mind, addressing a key limitation of ROS 1.

Understanding Real-Time Requirements in Robotics​

  • Hard Real-Time: Missing a deadline can lead to catastrophic failure (e.g., controlling a robot arm during surgery).
  • Soft Real-Time: Missing a deadline degrades performance but doesn't cause system failure (e.g., updating a GUI display).
  • Firm Real-Time: Similar to soft real-time, but performance degradation beyond a certain point makes the result useless.

ROS 2's Efforts Towards Real-Time Performance​

ROS 2 incorporates several features to improve real-time performance:

  • DDS Middleware: Many DDS implementations are designed for real-time performance.
  • Managed Nodes (Lifecycle Nodes): Enable predictable startup and shutdown, reducing non-deterministic delays.
  • Executor Enhancements: Improved mechanisms for controlling thread scheduling and execution order.
  • Real-Time Operating Systems (RTOS): ROS 2 is designed to run efficiently on RTOS like Xenomai, QNX, or patched Linux kernels (PREEMPT_RT), which prioritize deterministic execution.

Hard vs. Soft Real-Time​

While ROS 2 can be configured for hard real-time applications with an appropriate RTOS, it generally aims to provide strong guarantees for soft real-time performance out-of-the-box on standard Linux. Achieving true hard real-time often requires specialized hardware, kernel configurations, and careful application design.

6.6 Security in ROS 2 Networks​

Security was a significant afterthought in ROS 1, making it vulnerable in many deployment scenarios. ROS 2 addresses this by integrating robust security features directly into its core, leveraging the security capabilities of DDS. SROS 2 (Secure ROS 2) refers to the set of security mechanisms available in ROS 2.

SROS 2 (Secure ROS 2)​

SROS 2 provides:

  • Authentication: Verifying the identity of nodes and participants in the ROS 2 graph.
  • Authorization: Controlling what authenticated nodes are allowed to do (e.g., which topics they can publish to or subscribe from).
  • Encryption: Protecting the confidentiality and integrity of data exchanged over the network.

Authentication, Authorization, Encryption​

  • Authentication: Achieved using X.509 certificates and Public Key Infrastructure (PKI). Each ROS 2 participant (node, daemon) has a certificate to prove its identity.
  • Authorization: Handled by Access Control Lists (ACLs) that define permissions (publish, subscribe, call, create, etc.) for each participant on specific topics, services, or actions.
  • Encryption: Data transmitted over DDS can be encrypted, preventing eavesdropping.

Key Management and Access Control​

Managing security in ROS 2 involves:

  • Key Generation: Creating cryptographic keys and certificates for each participant.
  • Key Distribution: Securely distributing these keys to the respective nodes.
  • Access Control Policies: Defining and enforcing ACLs to implement fine-grained permissions.

These security features are critical for deploying ROS 2 systems in sensitive environments, such as industrial settings, medical applications, or defense systems, where unauthorized access or data tampering could have severe consequences.