ROS Graph

• A ROS-based system consists of a collection of nodes that execute code and communicate with each other, either locally or over the network.
• The nodes and are connected to each other via topics which are directed communication channels
  • nodes can be viewed as vertices in a communication graph and topics are directed edges
  • There are also other communication methods, such as services and actions that can connect nodes
• Every entity in the ROS graph (nodes, topics, etc) is labeled with a unique name, and can be referenced using that name.
• In ROS 2 nodes can discover each other automatically, even across a local area network
• ROS 1 required a central process called roscore to manage all traffic between nodes
• Aspects of the ROS Graph can be inspected with the ros2 command line tool
• The ROS Graph can be visualized interactively with rqt and rqt_graph

The design of ROS 2 involves several layers of abstraction, which can roughly be summarized as follows:

1. ROS Client Libraries provide the interface that most ROS 2 users interact with.
   • Programming-language-specific API libraries that abstract away the low-level details of communication.
   • Users use concepts like Nodes, Topics, Services, Actions, and Parameters
   • Built top of the ROS Middleware layer
2. The ROS Middleware (rmw) is an abstract layer that interfaces between ROS 2 and different Middleware vendors
   • This layer enables changing the underlying communication protocols without changing the user-facing client API

3 Middleware Implementation is what is used to actually send data

• Prior to kilted all ROS middleware was based on a standard protocol called Data Distribution Service (DDS)
• Beyond kilted there is also a ROS middleware implementation available based on Zenoh

• Quality of Service settings determine polices for how data is handled when data is being exchanges between nodes
• QoS determines what to do various scenarios such as communication over an unreliable connection or when messages are coming in too fast to be processed.
• Generally nodes must have the same QoS settings to communicate properly.

• A Node in ROS executes code and communicates with other nodes
• Nodes use ROS client libraries to interact with other nodes and the ROS system.
  • Client libraries are programming-language specific APIs and are how ROS is actually used when writing ROS software
  • rclpy is the Python client library.
  • rclcpp is the C++ client library.
  • rcl is the C client library, upon which the other client libraries are built.
• Nodes can run on multiple machines on a network and communicate with each other using topics, services, actions, and parameters

• Node Tutorial
• ros2 node is a command that is used to interact with running nodes from the command line.
• Start a node with ros2 run <package> <node>
• Nodes can also take command-line arguments
• To kill a node, kill the process it is running in using standard Linux commands such as kill or pkill

• Topics are labeled channels for communication between nodes
• A node sends information to nodes that subscribe by publishing a message to a topic.
• A node receives information from nodes that publish by subscribing to a topic.
• Every topic has a message type that determines what information is sent over the topic
• Nodes can subscribe and publish to any number of topics
• Topics are a many-to-many communication channel: any number of nodes may publish or subscribe to a given topic.
• Publishers do not know what nodes are subscribed or whether they receive the message
• Topics are the primary method for communicating streaming data in ROS

• Topics Tutorial
• ros2 topic provides commands for investigating topics.
• rqt_plot (ros2 run rqt_plot rqt_plot) can plot a topic value over time
  • An rqt plot can also be added to the GUI when running rqt
• rqt also provides plugins for working with topics.

• Services provide a request/response mechanism for inter-node communication.
• A node provides a service by creating a service server (sometimes referred to as just a server).
• A node calls a service by creating a service client (sometimes referred to as just a client).
• A service client sends a request to a service server and expects a response
• Every services has a service type that determines the data that is sent in both the request and the response.
• Services are many-one communication channels: Each service has exactly one server, but multiple clients can connect to the same server.
• A service client always expects a response from a service server, or it is an error.
• Services are useful for sending infrequent signals to a node or for asking a node to perform a calculation.

• Services Tutorial
• ros2 service provides commands for investigating services.
• rqt also provides plugins for working with services.

• [[Actions enable nodes to initiate a long-running task and receive periodic feedback.
• Actions consist of three parts: a goal, a result, and feedback.
  • The action client initiates a goal and waits for a result from the action server (analogously to the request and response of a service)
  • While the action client is waiting, the action server can periodically publish feedback (over a topic) that the client can subscribe to.
  • When the action is complete the server sends a result (much like a response for a service).
• Clients can send multiple goals to the action server while the initial request is pending.
• Clients can also send a cancel goal to the action server to tell it to end the action.
• Actions are implemented, at a lower-level, in terms of services and topics.

• Action Tutorial
• ros2 action provides commands for examining actions.
• rqt also provides plugins for working with actions.
• The underlying services and topics used by the action are hidden by default
  • Passing --include-hidden-topics to ros2 topic and --include-hidden-services to ros2 service provides access to these hidden topics and services

• Interfaces are a generic name for Topics, Services, and Actions (the interface to a node).
  • Topics have an associated Message Type that determines the layout of the message published to the topic.
  • Services have an associated Service Type that determines the layout of the associated request and response.
  • Actions have an associated Action Type that determines the layout of the request, result, and feedback.
  • An Interface Type generically refers to Message Type, Service Type or Action Type.
  • Sometimes, in conversation we say "Interface", "Message", "Service" or "Action" to mean the associated type: context makes the distinction.
• ROS Interface Types are specified using the Interface Definition Language (IDL):
  • Message Types are specified in <pkg>/msg/<MessageType>.msg files
  • Service Types are specified in <pkg>/srv/<ServiceType>.srv files
  • Action Types are stored in <pkg>/action/<ActionType>.action files

• Parameters enable storing configuration values for a node.
• Parameters are used as settings that can be accessed by all ROS nodes and modified by the user to change node behavior.
• Often nodes read parameters once when they start, but it is possible for a Node to update it's value when a parameter changes.
• Parameters can store strings, integers, floats, dates, times, and lists.

• Parameter Tutorial
• Use ros2 param to perform actions on nodes.

• In ROS 1 parameters are stored in a central server called the ROS parameter server.
• The behavior of a central parameter server can be emulated by creating a node that is only used to store parameters.

• Launch files enable multiple nodes to be started with a single command
• In ROS 2 there are 3 formats for launchfiles
  • XML: The format as used in ROS 1. Directly declares what nodes are running but can perform minimal logic.
  • YAML: Another format for writing what is essentially the same as an XML launchfile (do you like tags or indentation?).
  • Python: python scripts that use the ROS 2 launch API to configure and run nodes. The most flexible and powerful but also most complicated
• Effectively, launchfiles provide a method for declaring the structure of the ROS graph on a single computer
  • In ROS 1 it was also possible to launch nodes on remote computers, but that functionality has not been implemented

• Launchfile Tutorial
• ros2 launch lets you run and interact with launchfiles.
• Strive to have one launchfile completely start your project

Bags enable you to record ROS communication data across the graph and play it back later.

• Use ros2 bag to interact with and record bags.
• Running robotics experiments is often frustrating and difficult. Capturing the data from a run and testing different algorithms and parameters on it is extremely useful.
• rqt has a plugin called rqt_bag that enables interaction with bagfiles.

• Logging is used to record important diagnostic information from ROS nodes
• There are five severity levels: DEBUG, INFO, WARN, ERROR, FATAL that can be configured and messages can be filtered based on severity
• Logs are saved to files, published on the /rosout topic and can also be viewed in real time using rqt_console

• rqt_console tutorial
• Configuring Logging
• When running a node passing --ros-args --log-level LEVEL sets the logger level
  • To specify a particular node within a container use --ros-args --log-level node_name:=DEBUG