ROS Topic

A synchronous, request-response communication pattern for executing remote procedure calls (RPCs). Unlike the many-to-many, streaming nature of topics, a service provides a one-to-one, blocking interaction:

• A client node sends a request message and blocks execution until it receives a reply.
• A server node processes the request and returns a single response message.
• Ideal for on-demand tasks like querying a sensor's status, performing a calculation, or triggering a discrete action where an immediate, guaranteed result is required.

An asynchronous, long-running task interface built on top of topics. It extends the service model to handle operations that take a significant time to complete, providing feedback, cancellation, and preemption capabilities.

• A client sends a goal (e.g., 'navigate to position X,Y').
• An action server executes the goal, publishing periodic feedback messages (e.g., '50% complete') on a dedicated topic.
• Upon completion, the server sends a result message (e.g., 'succeeded' or 'aborted').
• This pattern is fundamental for navigation, manipulation, and other complex behaviors where progress monitoring is critical.

A configuration variable stored on a centralized parameter server that nodes can access at runtime. Parameters are used for system configuration rather than continuous data flow.

• Nodes can get, set, and list parameters.
• Parameters support dynamic reconfiguration; nodes can subscribe to parameter events to update their behavior when a value changes.
• Defined in YAML files or set via launch files and the command line.
• Typical uses include setting control gains, sensor thresholds, algorithm modes, and operational limits without recompiling code.

The strictly typed data structure transmitted over topics and services. A .msg file defines the schema for this data, specifying field names and types (e.g., std_msgs/Header, geometry_msgs/Pose, sensor_msgs/LaserScan).

• Messages enable language-agnostic communication; a C++ node can publish a message that a Python node subscribes to seamlessly.
• The ROS build system generates language-specific code (classes in C++, modules in Python) from .msg definitions for serialization/deserialization.
• Complex, nested messages can be built by composing simpler, standard message types, promoting data interoperability across the ecosystem.

The fundamental executable process within a ROS graph. A node is a module that performs a specific computation (e.g., sensor driver, planner, controller).

• Nodes are loosely coupled; they discover and communicate with each other dynamically via topics, services, and actions.
• A single robot system typically comprises many nodes running concurrently, each responsible for a discrete function.
• This modular architecture allows for independent development, testing, and failure recovery; a crashing perception node does not necessarily halt the motor control node.

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

• The graph comprises nodes, topics, services, and actions.
• Tools like rqt_graph provide a real-time visualization of this graph, showing which nodes are publishing to or subscribing from which topics.
• Understanding the graph is crucial for system debugging, performance analysis, and architectural design, as it reveals data flow bottlenecks and unwanted couplings.