Publisher-Subscriber Pattern

A Publisher is a software component that produces and sends messages without knowledge of the receiving entities. Its sole responsibility is to categorize messages into logical channels called topics and dispatch them to the messaging infrastructure.

• Key Role: Data source. Examples include a sensor driver publishing LiDAR point clouds or a localization node publishing pose estimates.
• Decoupling: Publishers are unaware of subscriber existence, count, or location, enabling dynamic system scaling.
• Topic Declaration: Publishers typically advertise the topics they will publish to, allowing the middleware to manage subscriptions.

A Subscriber is a component that expresses interest in one or more topics and receives relevant messages asynchronously. It implements a callback function that is invoked by the middleware when a matching message arrives.

• Key Role: Data consumer. Examples include a path planner subscribing to pose topics or a visualization tool subscribing to sensor data.
• Subscription: Subscribers declare their topic interests. The middleware's broker (if present) filters and routes messages accordingly.
• Loose Coupling: Subscribers operate independently of the publisher's lifecycle and implementation details.

A Topic is a named logical channel that categorizes messages. It is the primary mechanism for decoupling publishers and subscribers, acting as a content-based filter.

• Named Identifier: Topics are often string-based (e.g., /camera/color/image_raw, /odometry/filtered).
• Type-Safety: In strongly-typed middleware (e.g., ROS 2), topics are associated with a specific message data type (schema).
• Namespace Hierarchy: Topics can be organized hierarchically (using / separators) for logical grouping and system management.

A Message is the discrete unit of data transmitted from a publisher to subscribers. It is a structured data object conforming to a predefined schema or interface definition.

• Structure: Typically defined via Interface Definition Language (IDL), specifying fields and data types (e.g., integers, floats, arrays, nested structures).
• Serialization: Messages are serialized into a binary format (e.g., CDR, JSON, Protobuf) for transmission over the network or shared memory.
• Content: Carries the state or event information, such as a sensor reading, a computed trajectory, or a system command.

The Middleware is the communication infrastructure that implements the Pub/Sub logic. In a brokered architecture, a central message broker (e.g., RabbitMQ, Apache Kafka) acts as an intermediary. In a brokerless design (e.g., DDS, ROS 2), discovery and routing are handled peer-to-peer.

• Core Functions: Handles topic discovery, message routing, serialization/deserialization, and quality-of-service (QoS) enforcement.
• Discovery Protocol: Automatically detects publishers and subscribers on the network (e.g., using Simple Service Discovery Protocol or the DDS Discovery Protocol).
• QoS Policies: Manages delivery guarantees like reliability (best-effort vs. reliable), durability, history, and deadlines.

Quality of Service (QoS) Policies are a set of configurable parameters that define the contractual behavior for message delivery between publishers and subscribers. They are critical for real-time robotic systems.

• Common Policies:
  • Reliability: RELIABLE (guaranteed delivery with retries) vs. BEST_EFFORT.
  • Durability: VOLATILE (messages to future subscribers) vs. TRANSIENT_LOCAL (last message cached for late-joining subscribers).
  • History: KEEP_LAST (keep N most recent) vs. KEEP_ALL.
  • Deadline: The maximum expected period between successive messages.
  • Liveliness: How a participant signals it is still "alive."
• Policy Matching: A connection is only established if the QoS profiles of the publisher and subscriber are compatible.

In robotic perception, sensors like LiDAR, cameras, and IMUs publish raw or processed data to specific topics (e.g., /camera/color/image_raw, /scan). Subscribers, such as sensor fusion nodes or object detection algorithms, consume this data without knowing the source. This loose coupling allows for easy swapping of sensor hardware or algorithms without rewriting the entire system. For instance, a new depth camera can be integrated by simply publishing to the existing /depth topic.

Control algorithms compute desired joint velocities or torques and publish them to command topics (e.g., /cmd_vel for a mobile base, /arm/joint_trajectory for a manipulator). The low-level motor controller subscribes to these topics and executes the commands. This separation ensures the control logic is independent of the specific motor driver or Field-Oriented Control (FOC) implementation. The pattern's asynchronous nature is critical for meeting the hard real-time requirements of actuator loops.

A Simultaneous Localization and Mapping (SLAM) node publishes the robot's estimated pose (/odom) and the map (/map). Multiple consumers, such as the navigation stack, a digital twin visualizer, and a multi-robot coordinator, can subscribe to this single source of truth. This prevents data duplication and ensures all system components operate on a consistent state estimate. The pattern efficiently handles the high-bandwidth data flow from sensor fusion pipelines to the world model.

In a heterogeneous fleet, each robot runs its own publish-subscribe graph. For coordination, a central orchestrator node can subscribe to status topics from all robots (e.g., /robot1/battery, /robot2/position) and publish high-level task assignments. Robots can also publish to shared 'team' topics for direct peer-to-peer communication, enabling behaviors like swarm intelligence or collaborative transport without a central bottleneck. This architecture scales effectively as the number of agents increases.

A Hardware Abstraction Layer (HAL) driver node publishes raw device data and subscribes to command topics, isolating application logic from hardware specifics. Concurrently, diagnostic data is published on separate topics (e.g., /motor/temperature, /network/latency). A dedicated diagnostics aggregator subscribes to all these streams, enabling system-wide observability and predictive maintenance without impacting the performance of the primary control loops. This separates concerns between operational data and telemetry.

DDS is an Object Management Group (OMG) standard for scalable, real-time data exchange. It is the underlying protocol for ROS 2 and other high-performance systems.

• Core Mechanism: Implements a global data space where publishers and subscribers anonymously exchange data defined by a Topic and a Type. Discovery is handled dynamically.
• Determinism: Provides configurable QoS policies such as DEADLINE, LIVELINESS, and RELIABILITY to guarantee data delivery within specified temporal bounds.
• Vendors: RTI Connext DDS and Eclipse Cyclone DDS are common implementations used in aerospace, automotive, and robotics for their hard real-time capabilities.

For the most demanding real-time constraints, robotic systems often implement a custom, lightweight pub/sub layer using inter-process communication (IPC) and shared memory.

• Mechanism: A central memory-mapped ring buffer acts as the topic. Publishers write directly to the buffer; subscribers read from it. Synchronization is managed via lock-free primitives or atomic operations to avoid priority inversion.
• Determinism: Eliminates serialization/deserialization overhead and kernel context switches, achieving sub-microsecond latencies and minimal jitter.
• Use Case: Found in bare-metal or RTOS-based control loops where a sensor driver (publisher) must feed data to a state estimator (subscriber) with a worst-case execution time guarantee.

Model Predictive Control (MPC) is an advanced control algorithm that uses an internal dynamic model to predict future system states and iteratively solves an optimization problem to determine optimal control inputs. In robotic architectures:

• The state estimator often acts as a Publisher of the current system state.
• The MPC solver is a Subscriber to this state topic.
• The MPC then publishes optimized actuator commands (e.g., joint torques, wheel velocities) to a control topic. This pub/sub decomposition allows the computationally heavy MPC optimization to run at a different, often slower, rate than the low-level actuator Subscribers, facilitating modular and scalable control system design.

Hardware-in-the-Loop (HIL) Testing is a validation technique where real controller hardware operates in a closed loop with a real-time simulator modeling the robot and environment. The Publisher-Subscriber pattern is central to this setup:

• The real-time simulator (e.g., running on a Speedgoat target) publishes simulated sensor data (IMU, LiDAR) on specific topics.
• The actual robot controller (Device Under Test) subscribes to these topics, processes the data, and computes control commands.
• The controller then publishes these commands back to the simulator, which calculates the next system state. This creates a deterministic, repeatable, and safe test environment for validating the entire robotic software stack, including all pub/sub communication, before physical deployment.

Worst-Case Execution Time (WCET) is the maximum possible time a specific task or piece of code can take to execute on given hardware. In real-time pub/sub systems, analyzing WCET is critical for schedulability:

• The execution time of a Subscriber's callback function must have a known and bounded WCET.
• The time to serialize, publish, and transmit a message must also be bounded.
• System designers use WCET analysis to ensure that even in the worst-case scenario, all Publisher and Subscriber tasks meet their deadlines, guaranteeing the stability of control loops. Failure to account for WCET can lead to priority inversion, jitter, and missed deadlines, causing system failure.