ROS Basics

The ROS ecosystem consists of a collection of tools, software, and documentation. These are used to describe, implement, and inspect a ROS program, which consists of multiple processes (called nodes) that run in parallel and communicate with each other using inter-process communication.

• https://docs.ros.org: The main documentation for ROS
• The official ROS Tutorials. The beginner tutorials are especially worth doing.
• https://index.ros.org The ROS index tracks ROS packages and links to documentation for them.
  • This page is extremely useful and should be your first stop when trying to learn about a package.
• https://docs.ros.org/en/jazzy/p Package-level API documentation (this still seems to be somewhat of a work-in progress).
• https://wiki.ros.org - The ROS wiki is the main documentation for ROS 1.
  • ROS 2 documentation should be preferred, but for packages in both ROS 1 and ROS 2 the documentation has not yet fully transitioned and the ROS 1 documentation mostly applies.
• https://robotics.stackexchange.com - The preferred Q & A website for asking ROS questions.
  • ROS deprecated https://answers.ros.org on August 11, 2023 in favor of the robotics stack exchange website. It is still available in read-only mode.
• ROS Enhancement Proposals (REP) - Documents ROS design decisions and best practices.
• Built-in documentation: Most ros tools accept a --help or -h argument to display their help.
• External Documentation: Sometimes the package itself has an external documentation website (often linked on the ROS wiki, often on the repository page).
• Some of the tools used in ROS are actually maintained separately from ROS and have their own documentation as well.
• The source code is often the ultimate documentation. Do not be afraid to read the code.
• Part of this course is about learning how to use the documentation, so not all the answers will be provided in these notes or in lecture!

• By default ROS 2 commands are not on your PATH and cannot be found
• At least one ROS 2 workspace must be "sourced" before you can run ROS 2
• When you installed ROS 2 you added the line source /opt/ros/jazzy/setup.bash to the ~/.bashrc file.
  • This line puts ros2 commands on the PATH so that you can use them
  • If the ros2 command is not found, it likely means the workspace has not been sourced
• The ROS2 Configuring Environment Tutorial goes through the process of setting up the ROS 2 environment

Packages are the basic organization unit for ROS components that can be installed and uninstalled as a single unit.

• Packages are created from source code and data (e.g., python files, C++ files, configuration files, interface descriptions).
• Packages are distributed either as source code (e.g., as a git repository or a tarball) or as a binary file (e.g., a debian (.deb) file).
• Some packages rely on other packages to function. If package A depends on packages B and C then packages B and C are dependencies of package A.
• Many ROS packages depend on packages that are distributed with Ubuntu.
  • Packages distributed with the operating system (e.g., Ubuntu) are called system dependencies.

• A Node in ROS executes code and communicates with other nodes.

• A Node is often its own process, but in ROS 2 multiple nodes may run under a single process (e.g., to reduce communication overhead).

  Details

  • A node needs to be made in a specific way to be composable. A Composable Node is referred to as a component.
  • Composable nodes can currently only be written in C++.
  • Tutorial on Composable Nodes
• Nodes use ROS client library to connect with other nodes.
  • rclpy is the Python client library.
  • rcl is the C client library, upon which the other client libraries are built.
  • rclcpp is the C++ client library.
• Each node communicates with other nodes (which may be running in the same process, different processes on the same computer, or on different computers) to form a complete robotic system.
• In ROS 2 Lifecycles may be used to manage and control when and how a node runs.
  • Lifecycle nodes can currently only be written in C++.
• Use ros2 node list to list all running nodes.
• See the Nodes conceptual documentation for more information.

In ROS, there are a few methods for nodes to exchange information. These modes work whether the nodes are running within the same process, on different processes on the same computer, or on different computers.

• All running nodes in a ROS system can be thought of as vertices (aka nodes) in a computation graph.
• All topics in a ROS system can be thought of as the directed edges in a computation graph.
• The ROS graph can be visualized in rqt or by using rqt_graph.
• ROS 2 communication is based on a standard message-passing protocol called Data Distribution Service (DDS)
  • The standard uses Real-Time Publish Subscribe (RTPS) to define a common data-exchange format between DDS vendors.
  • The ROS 2 client libraries provide abstractions around this protocol. via the ROS Middleware (rmw).
  • Multiple vendors provide implementations of DDS, but rmw enables a user to theoretically change DDS implementations without affecting the rest of the code.
  • There are different reasons (both technical and non-technical) for using different DDS implementations, see About different ROS 2 DDS/RTPS vendors for details
  • We will use the default DDS implementation.
• In ROS 2, nodes are able to discover and connect to each other automatically, but this can also be changed to be more manual.
• Quality of Service settings determine polices for how data is handled when being exchanged (whether via topics or services):
  • 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.
  • We will be using the default QoS settings.

ROS 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.
• Use ros2 param to perform actions on nodes.
• Typically, nodes read parameters when they start, however, in ROS 2, a callback can respond to parameter changes.
• Parameters can store strings, integers, floats, dates, times, and lists.
• Oftentimes, parameters are set in Launchfiles, to provide each node you are starting with the proper configuration information
• See the Parameters conceptual documentation for more information.

Launchfiles enable multiple nodes to be started with a single command.

• In ROS 2 there are 3 formats for a launch file
  • Python: python scripts that use the ROS 2 launch API to configure and run nodes. The most flexible and powerful but also most complicated.
  • XML: The format as 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?)
• ros2 launch lets you run and interact with launchfiles.
• Strive to have one launchfile completely start your project

Bags enable you to capture data from ROS topics to a file and play them back in real time.

• 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.

Nodes can log information at different logger levels, indicating the severity of the message.

• There are five verbosity levels: DEBUG, INFO, WARN, ERROR, FATAL.
• Log data can also be viewed in real time using rqt_console
• The RCUTILS_CONSOLE_OUTPUT_FORMAT environment variable controls the formatting of log messages
• When running a node passing --ros-args --log-level LEVEL sets the logger level
  • To specify a particular node use --ros-args --log-level node_name:=DEBUG
• Tutorial on Logging
• Currently, the logger level can only be configured externally after a node is running if the node has enabled logging services, and there are limitations.

• ros2 doctor can help point out problems with your ROS setup

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

1. DDS - Data Distribution Service handles the low-level communication
   • DDS is a standard. There are multiple DDS implementations provided by different vendors
   • Sometimes DDS issues leak into your code, but in general, you should be able to use ROS 2 while mostly ignoring DDS details
2. ROS Middleware is an abstract layer that interfaces between ROS 2 and different DDS vendors
   • There is also work to make a ROS middleware that does not use DDS
   • This is an abstraction layer that allows ROS 2 to switch between different underlying communication methods without changing the user experience (too much)`
3. ROS Client Libraries provide the interface that most ROS 2 users interact with. This is the programming-language-specific API libraries that abstract away the low-level details of communication. It is built on top of the ROS Middleware layer