Intro to ROS¶
The Robot Operating System (ROS) is a central component to our drone’s autonomy. ROS offers a powerful set of tools for interfacing between multiple heterogeneous computer processes, which is a common theme of robotics due to that fact that robots are often composed of a system of processors, sensors, and actuators.
The following set of video lectures, slides, and blog offer a concise introduction to ROS
ROS Website: Computation Graph Concept
The following ETH and Erle lectures reference an older version of ROS called
indigo. At the time of this writing we use a version called
kinetic (and will likely be moving to a version called
melodic in the near future). For the most part, any commands that explicitly reference
indigo can substituted with the same command where
kinetic is used in place of
source /opt/ros/indigo/setup.bash –>
Communication Pipeline - Once you’ve completed watching the lecture, practice what you’ve learned in the practical
Further Practice - For additional tutorials, see the ROS website
The following is taken almost directly from http://wiki.ros.org/ROS/Concepts and reproduced here for completeness
Computation Graph - The Computation Graph is the peer-to-peer network of ROS processes that are processing data together. The basic Computation Graph concepts of ROS are nodes, Master, Parameter Server, messages, services, topics, and bags, all of which provide data to the Graph in different ways.
Master - The ROS Master provides name registration and lookup to the rest of the Computation Graph. Without the Master, nodes would not be able to find each other, exchange messages, or invoke services.
Nodes - Nodes are processes that perform computation. ROS is designed to be modular at a fine-grained scale; a robot control system usually comprises many nodes. For example, one node controls a laser range-finder, one node controls the wheel motors, one node performs localization, one node performs path planning, one Node provides a graphical view of the system, and so on. A ROS node is written with the use of a ROS client library, such as roscpp or rospy.
Topics - Messages are routed via a transport system with publish / subscribe semantics. A node sends out a message by publishing it to a given topic. The topic is a name that is used to identify the content of the message. A node that is interested in a certain kind of data will subscribe to the appropriate topic. There may be multiple concurrent publishers and subscribers for a single topic, and a single node may publish and/or subscribe to multiple topics. In general, publishers and subscribers are not aware of each others’ existence. The idea is to decouple the production of information from its consumption. Logically, one can think of a topic as a strongly typed message bus. Each bus has a name, and anyone can connect to the bus to send or receive messages as long as they are the right type.
Messages - Nodes communicate with each other by passing messages. A message is simply a data structure, comprising typed fields. Standard primitive types (integer, floating point, boolean, etc.) are supported, as are arrays of primitive types. Messages can include arbitrarily nested structures and arrays (much like C structs).
Parameter Server - The Parameter Server allows data to be stored by key in a central location. It is currently part of the Master.
Services - The publish / subscribe model is a very flexible communication paradigm, but its many-to-many, one-way transport is not appropriate for request / reply interactions, which are often required in a distributed system. Request / reply is done via services, which are defined by a pair of message structures: one for the request and one for the reply. A providing node offers a service under a name and a client uses the service by sending the request message and awaiting the reply. ROS client libraries generally present this interaction to the programmer as if it were a remote procedure call.
Bags - Bags are a format for saving and playing back ROS message data. Bags are an important mechanism for storing data, such as sensor data, that can be difficult to collect but is necessary for developing and testing algorithms.