ROS Node

A ROS Node is designed to be a single-purpose process that performs one specific, well-defined computational task within a larger robotic system. This modular design principle, often summarized as "one node, one job," promotes system clarity, ease of debugging, and independent development.

• Examples: A node might be solely responsible for reading data from a specific LiDAR sensor, performing SLAM, calculating motor control commands, or managing a graphical user interface.
• Benefits: This separation of concerns allows developers to update, restart, or replace individual nodes without bringing down the entire system, enhancing robustness and maintainability.

Nodes operate within a decentralized, peer-to-peer network known as the ROS graph. They are not managed by a central master (in ROS 2) and discover each other dynamically. Communication is achieved through several well-defined interfaces:

• Topics: For asynchronous, many-to-many data streaming (publish/subscribe).
• Services: For synchronous, request-response interactions.
• Actions: For asynchronous, long-running tasks with feedback and cancellation.
• Parameters: For runtime configuration accessible via a parameter server.

This model allows complex systems to be built from simple, interconnected components.

A core strength of ROS is that nodes can be written in different programming languages and still interoperate seamlessly. This is enabled by ROS Client Libraries (RCLs), which provide language-specific APIs that handle message serialization, communication protocols, and node lifecycle.

• Primary Libraries: rclcpp for C++, rclpy for Python.
• Other Supported Languages: Java, Rust, and others through community packages.
• Interoperability: A perception node written in C++ for performance can publish data to a planning node written in Python for rapid prototyping, with no modification required. The strict message type definitions (.msg files) ensure data compatibility across language boundaries.

In ROS 2, nodes can be implemented as Lifecycle Nodes, which follow a managed state machine. This provides deterministic control over initialization, activation, error recovery, and shutdown, which is critical for safety and reliability in production systems.

• Key States: Unconfigured, Inactive, Active, Finalized.
• Controlled Transitions: A system manager can command a node to configure, activate, deactivate, or cleanup. A node only processes data (e.g., publishes/subscribes) when in the Active state.
• Use Case: This allows for orderly system bring-up where hardware interfaces are configured before controllers are activated, and enables safe error recovery by deactivating a faulty component.

Nodes can be dynamically configured at runtime using the ROS Parameter system. Parameters are key-value pairs (e.g., max_velocity: 2.0) stored on a parameter server that nodes can access.

• Dynamic Updates: Parameters can be changed via command-line tools or graphical interfaces while the node is running. The node can subscribe to parameter events to reconfigure its behavior immediately in response.
• Typical Uses: Tuning control gains, setting sensor thresholds, updating navigation waypoints, or switching operational modes without restarting the node or the entire system.
• Declaration: Nodes declare which parameters they use, optionally providing default values and descriptors.

The execution logic of a node—how it handles incoming messages, service calls, and timers—is governed by a ROS 2 Executor. The executor is responsible for spinning the node, which involves waiting for work and invoking the appropriate callback functions.

• Single-Threaded Executor: Processes all callbacks sequentially in a single thread. Simple but can lead to latency if one callback blocks.
• Multi-Threaded Executor: Uses a pool of threads to execute callbacks in parallel, improving responsiveness for independent tasks.
• Custom Scheduling: Developers can implement specialized executors for real-time or priority-based scheduling needs.
• Composition: Multiple nodes can share a single executor within a process, reducing overhead compared to running each node in its own process.

A named bus for asynchronous, many-to-many data exchange using a publish-subscribe model. A node publishes messages to a topic, and any number of subscriber nodes can receive them concurrently without direct coupling.

• Key Use Case: Streaming sensor data (e.g., camera images, LiDAR scans, joint states).
• Characteristics: Fire-and-forget, best for continuous data flows. No guarantee a specific subscriber receives the message.

A synchronous, request-response communication mechanism. A client node sends a request to a server node and blocks execution until it receives a reply.

• Key Use Case: Performing discrete computations or state changes, like calculating a path or toggling a setting.
• Characteristics: Provides direct feedback and is blocking. Ideal for transactional operations where an immediate answer is required.

An asynchronous interface for long-running tasks. Built atop topics, it allows a client to send a goal to a server, receive periodic feedback during execution, and a final result upon completion or cancellation.

• Key Use Case: Navigation, manipulation, or any task with duration (e.g., "move to position X," "pick up object Y").
• Characteristics: Supports preemption, progress monitoring, and structured termination, making it more complex but powerful than services.

A configuration variable stored on a centralized or node-specific parameter server. Nodes can retrieve, set, and monitor these values at runtime.

• Key Use Case: Tuning system behavior without recompiling code (e.g., control gains, timeout limits, operational modes).
• Characteristics: Supports dynamic reconfiguration. Changes can trigger parameter events to notify nodes of updates.

The runtime network representing all active ROS entities and their connections. It is a visual and conceptual map of the system's communication topology.

• Components: Includes nodes, topics, services, and actions.
• Key Use Case: Debugging and system introspection. Tools like rqt_graph visualize the graph to understand data flow and identify disconnected components.
• Characteristics: Dynamic—nodes can join or leave, and connections can be remapped, changing the graph during operation.

A language-specific API that provides the core programming interface for creating ROS 2 nodes. It abstracts the underlying middleware (DDS) complexities.

• Primary Libraries: rclcpp for C++ and rclpy for Python.
• Functionality: Provides objects and methods to create nodes, publishers, subscribers, service servers/clients, action servers/clients, and manage parameters.
• Key Use Case: The fundamental SDK for any developer writing ROS 2 application code.