ROS Basics

• https://wiki.ros.org - The ROS wiki should be your first stop for documentation. Some packages are better documented than others
  • The wiki contains a getting started overview here: https://wiki.ros.org/ROS/StartGuide.
• https://answers.ros.org - Ask questions about ROS. Often one of the developers will respond.
• https://docs.ros.org - Many packages wiki page have a "Code API" link that brings you to automatically generated API documentation for the package.
• ROS Enhancement Proposals (REP) - Documents ROS design decisions and best practices.
• Built-in documentation: Most ros tools accept a --help 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 github 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.

• Contains a collection of files such as source code, configuration files, message descriptions, service descriptions, libraries, data, and build files.
• Dependencies and other meta-information (such as the name and the author) are declared in the manifest file, called package.xml
• Multiple packages can be stored in a single version control (e.g., git) repository.
• Package contents are stored in a directory <pkg>, where <pkg> is the name of the package.
• rospack is a command-line tool to find information about packages
• Packages also have a CMakeLists.txt file, which is used by the build system to compile the package.
• The catkin_create_pkg tool can automatically create a package for you, providing boilerplate code that is needed.
  • Packages can also be created by hand simply by creating a package.xml and a CMakeLists.txt file.
• The rospack tool can be used to investigate dependencies for a ROS package

• Node is ROS's term for a process and is the basic unit of execution in ROS.
• It uses a ROS client library to connect with other nodes
  • rospy is the client library for python.
  • roscpp is the client library for C++
  • There are client libraries for other languages, but they are used less frequently
• A node is an executable, like any other on your computer, except it uses the ROS client library to adhere to ROS conventions and communicate with other nodes using XMLRPC, an inter-process communication protocol.
• The source code for ROS C++ nodes is conventionally stored under the <pkg>/src directory.
• The source code for python nodes is typically under <pkg>/scripts or <pkg>/nodes. These files usually do not have a .py extension
• The rosnode is the command line tool for getting information about nodes.
• The rosrun command lets you run a node.

• Nodes communicate with each other using messages, which define the structure of the data that is passed between nodes.
• Standard datatypes such as int64, int8, string, time, bool, float32, float64, and arrays thereof are supported
• Messages can be nested
• There are several standard message types that come with commonly used packages
• Messages are defined in .msg files and are stored under the <pkg>/msg directory.
• rosmsg is a command line tool for inspecting message types.

Topics are channels for communication between nodes

• A node sends a message over a topic by publishing it
• Other nodes may subscribe to the topic to receive the messages published to it
• A topic is associated with a single message type
• Any number of nodes may publish on or subscribe to a given topic.
• The publishing node does not know when or if a given subscriber receives a message.
• Sensor data and other important information about a robot is often published to specific topics
• rostopic is the command line tool for manipulating and inspecting topics
• rqt_plot generates real-time plots of topics over time

A Service implements a request/reply mechanism for inter-node communication.

• A service file .srv uses messages to define the request and reply data types. These files are typically stored in <pkg>/srv
• Services are used for sending infrequent signals to a node or for asking a node to perform a calculation
• The node initiating the request is called the client and the node receiving the request is the server
• There can be only one server for each Service.
• After initiating a request, the client can wait until a response is received
• rossrv is used to inspect service types
• rosservice is used to get information from and manipulate services.

Launchfiles are used to start groups of nodes and pass parameters to them.

• Conventionally, launchfiles are stored in <pkg>/launch and end with the .launch extension.
• roslaunch is the command-line tool for running launchfiles
• Many projects can be created by using existing packages and connecting their nodes/topics using launchfiles. Your projects, however, will require programming nodes!

The ROS Parameter Server stores values that can be used by ROS nodesoth

• Think of the Parameter server as a global python dictionary storing key-value pairs that can be accessed by any ROS nodes
• The purpose of ROS parameters is to store settings and information used by multiple nodes
  • The information typically does not change
• Parameters are used as settings that can be accessed by all ROS nodes and modified by the user
  • Use rosparam to interact with the parameter server from the command-line.
• Typically, nodes read parameters when they start. Subsequent updates to the parameters are ignored.
• 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

Every running ROS system executes roscore, which consists of the following components

• rosmaster, which coordinates connections between nodes
• Parameter Server, which enables sharing values between nodes. Typically used for data that does not change over the course of a run. Nodes communicate with the parameter server to get/set values.
• rosout, which is a node used for logging

Bags enable you to capture the data broadcast over a topic

• Captured data can be replayed or plotted
• rosbag is the tool that is used to manipulate bag files.
• 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_bag lets you visualize the contents of ros bags

The collection of nodes and the communication between them is collectively referred to as the ROS Computation Graph. Being able to view what nodes are running, what topics they publish and subscribe to helps with debugging ROS programs.

The graph can be viewed with

• rosgraph, which prints information about the current ROS computation graph.
• rqt_graph, which is a GUI for viewing the ROS computation graph.

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 level of logging for a specific node can be tuned using rqt_logger_level

• roswtf helps detect failures and diagnose issues.

This is a collection of deprecated terminology that you may see in the documentations from time to time.

• stack - Essentially what packages used to be called
• rosbuild - the old ros build system, prior to catkin
• wet vs dry packages - wet packages use catkin, dry packages use rosbuild