ROS Graph

A Node is the fundamental executable process within a ROS graph. Each node is designed to perform a specific, modular task, such as reading sensor data, performing computation, or controlling actuators. Nodes communicate with each other via the graph's communication mechanisms. A complex robotic system is typically composed of many nodes running concurrently, often distributed across multiple machines.

• Example: A /camera_driver node publishes images, a /detector node subscribes to them, and a /controller node subscribes to detection results to send motor commands.

A Topic is 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, all without direct knowledge of each other. Topics are ideal for continuous data streams like sensor readings or velocity commands.

• Characteristics: Asynchronous, unidirectional, and loosely coupled.
• Example: A LiDAR sensor node publishes a PointCloud2 message on the /scan topic, which is simultaneously consumed by a mapping node and an obstacle detection node.

A Service provides a synchronous, request-response communication mechanism. A client node sends a request to a server node and blocks execution until it receives a reply. This pattern is used for one-off computations or actions that require an immediate, definitive answer.

• Characteristics: Synchronous, bidirectional, and tightly coupled for the duration of the call.
• Example: A navigation node calls a /get_map service from a map server node to request the current occupancy grid, or a node calls a /toggle_led service to change the state of a hardware component.

An Action is an asynchronous interface for long-running tasks, built on top of topics. It involves a client sending a goal to a server, which then executes the task. The server streams periodic feedback to the client and sends a final result message upon completion or preemption. This is ideal for tasks like navigating to a pose or performing a complex manipulation sequence.

• Structure: Built from three topics: goal, feedback, and result.
• Example: A high-level task planner sends a MoveToGoal(x,y) action to a navigation action server, which provides feedback on progress (e.g., "50% complete") and a final result ("SUCCEEDED" or "ABORTED").

A Parameter is a configuration value stored on a centralized parameter server. Nodes can retrieve, set, and monitor these key-value pairs at runtime. Parameters allow for dynamic system reconfiguration without modifying code, making it easy to tune algorithms or adjust robot behavior.

• Use Cases: Setting camera frame rates, PID controller gains, or maximum velocity limits.
• Dynamic Reconfiguration: Nodes can subscribe to parameter events to be notified of changes and reconfigure themselves automatically.

Messages, Services, and Actions are defined by strictly typed data structures in interface definition files (.msg, .srv, .action). These files define the "contract" for communication, ensuring data consistency across nodes written in different programming languages (C++, Python).

• .msg: Defines the structure of data sent over a topic (e.g., sensor_msgs/Image.msg).
• .srv: Contains two message definitions: one for the request and one for the response.
• .action: Contains three parts: a goal definition, a result definition, and a feedback definition.
• Serialization: The ROS client libraries handle the serialization and deserialization of these defined types for network transmission.

The primary graphical tool for visualizing the live ROS graph. It renders nodes as ovals and topics as rectangles, with directed edges showing publish/subscribe relationships.

• Dynamic Updates: Automatically refreshes as nodes join or leave the graph.
• Namespace Filtering: Allows focusing on specific parts of a complex system.
• Debugging Use: Quickly identifies missing connections, orphaned nodes, or incorrect topic remappings.

Core command-line interface tools for querying the graph's state. These provide a scriptable, low-level view essential for automation and headless systems.

• ros2 node list: Lists all active nodes in the domain.
• ros2 topic list: Shows all active topics, with options to display topic types.
• ros2 node info <node_name>: Provides a detailed report of a node's subscriptions, publications, services, and actions.
• ros2 topic info <topic_name>: Displays the topic type and lists all publishing and subscribing nodes.

A Qt-based framework that hosts multiple plugin tools in a single window. It is the Swiss Army knife for ROS introspection, extending far beyond graph visualization.

• Plugin Ecosystem: Includes rqt_graph, rqt_console (for log viewing), rqt_plot (for data visualization), rqt_reconfigure (for dynamic parameters), and many more.
• Customizable Interface: Users can dock and arrange multiple plugins to create a tailored debugging dashboard.
• Runtime Inspection: Enables interactive probing of messages, service calls, and parameter states without stopping the system.

A diagnostic tool that checks a ROS 2 system for common configuration and network issues that can break the graph.

• Connectivity Checks: Verifies DDS discovery and communication between nodes.
• Environment Validation: Checks for correct ROS_DOMAIN_ID settings and workspace sourcing.
• Platform Reports: Generates a summary of the ROS 2 installation, version, and platform details to aid in troubleshooting.

A powerful, web-based visualization platform that connects to live ROS systems or plays back recorded bag data. It provides professional-grade, customizable dashboards.

• Multi-Panel Layouts: Simultaneously visualize the 3D scene, plot topic data, view images, and see the ROS graph.
• ROS 1 & ROS 2 Native Support: Connects directly via native ROS bridges or WebSocket.
• Data Playback: Synchronizes visualization panels with timestamps from ROS bag files for precise offline analysis.

Programmatic access to the graph topology via the rclpy and rclcpp client libraries, enabling custom monitoring and orchestration tools.

• get_node_names_and_namespaces(): Retrieves a list of all discoverable nodes.
• get_topic_names_and_types(): Gets all active topics and their message types.
• get_service_names_and_types(): Enumerates all available services.
• Use Case: Building custom health monitors, automated system validators, or dynamic node launchers that react to the graph's state.