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/iron/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!

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