Robot Operating System: Introduction
My ongoing goal is to build a self-navigating, pickup-and-deliver robot. Following the project outline article, I have researched the required hardware and software (phase 1) and built a moving robot prototype(phase 2). Now the goal is to use a robotics middleware software for simulating the robot with its chassis, movement abilities, and sensors.
During my research for robotics middleware, I stumbled upon the ROS project — an acronym for Robotic Operating System. ROS is the robotics middleware of my choice. It’s an outstanding open-source project with several years under its belt: A vast amount of software packages governing actuators, sensors and data processing libraries, and a complete tool suite from Command Line Tools to GUI tools for starting, querying, simulating and controlling your robot. is widely used in DIY robotic projects, and it is used in industry: Just recently, NASA announced to use ROS in their VIPER robot to explore the moon.
This article gives an overview to the core ROS concepts. In the following articles, I will detail how to setup ROS on a computer and how to start programming with it.
This article originally appeared at my blog admantium.com.
At its core, ROS provides high-level abstraction to govern a robot system. In essence, this system consists of interconnected Nodes. A node is any type of computer — a workstation, your laptop, your single board computer or microcontroller — that runs a ROS compatible program. The nodes form a coherent bus system, which provides a standard way for exchanging information via TCP/IP. ROS supports two types how Nodes can exchange information.
The first type is messages with a strictly defined datatype. Messages are published inside topics. Topics separate the ROS programs information logically. For example, a sensor could publish its information as a topic, or a topic provides information about the current position of the robot. Nodes can publish information to topics, or they can subscribe to a topic to get the information.
Source: ROS official documentation
The second type is services. They also define the concrete datatypes that will be used for the request and the response. Instead of the asynchronous communication involving topics, service clients can invoke the server directly (note: There can be only on server). A special type of service is an action — it works like a service, but also create a special topic in which it streams data back to the node that made the request.
_Source: ROS official documentation
ROS Communication Patterns
ROS core concepts can be selected or combined to allow different communication mechanism.
You can either use asynchronous, anonymous communication with the publish-subscribe system. In this mode, you need to take care that messages are produced and consumed at the same speed, or you need to define a maximum threshold value for the topic: Once its reached, new messages cannot be added anymore.
The other method is synchronous, directed communication with services and/or actions. Here you need to take care that the server responsible for answering the requests is available and can process the request.
To help with debugging communication, you can also use the following tools:
- Message playback: ROS stores all messages in files, which can be used for diagnosis or playback once new nodes join the
- Distributed data store: A global key-value store with which components can store values
When started, the ROS System build a global graph, a runtime peer-to-peer abstraction of all processes running on all nodes. This graph instantiates the ROS core concepts of nodes, messages, services. The master node defines the central lookup mechanisms with which the data structure. This data structure contains all nodes and messages of the runtime peer-to-peer network.
What are the implications? If you think of the hardware that defines your robot, you can think of each microcontroller or board as a different node, and all nodes need to run ROS. Also, you can host the ROS core node on a more powerful pc to provide additional computation power. With this setup you can build a robot with a camera. It streams the camera video feed to the master node, which processes the feed for information, e.g. object recognition. In some setups, it might also be enough to have an up-to-date micro board like the latest Raspberry Pi or die NVidia jetton as the ROS master core directly embedded in your robot.
ROS provides plenty tools to help in your robotics project.
Let’s start with the tools that will help you to explore how the core concepts are implemented.
rosnode- display information about the nodes running in your ROS system. See the complete
rosnode listor specific information with
rostopic- Explore and work with topics. Show detailed information about topics with
rostopic info. Or pass messages to a topic with
rostopic pub. And you can also get a live updated list of all exchanged messages of a topic with
rosmsg- Messages can be conveniently explored from the command line too. First of all, you can either see a complete list of all message types with
rosmsg list, or you can filter this list to a specific package with
rosmsg package. With
rosmsg showyou see the details of a message.
rosservice- Similar to topics, this command enables you to
listall services or get a detailed definition with
info, and you can also
rossrv- To display the service type information, this tool works with the very same sub-commands as the
ROS offers many more CLI tools, which help you to navigate the extensive package library, create and build your own package, and much more. See the official documentation for the complete list.
In addition to the CLI tools, there are also graphical tools to help you to explore and understand your ROS system.
The RQT Commons metapackage provides several QT applications to help exploring your ROS system graphically.
With the RQT Graph you can see a complete representation of all your ROS topics and their publishers/subscribers.
Source: Official Documentation
To record and filter the messages exchanged in ROS, use RQT Console.
_Source: Official Documentation
And to send messages, you can use RQT Publisher.
Source: Official Documentation
The starting point for any ROS project is to have a 3D model of your robot. The model is in essence an XML file which you can write in your favorite IDE. Once completed, you can use
rviz to get a 3D visualization of your robot. It’s also possible to load a world into this editor, a representation of objects in which your robot should be simulated. You can even move inside this representation with other ROS nodes
Source: RViz official documentation
Gazebo is a powerful tool with several capabilities. First, it extends RVIZ by providing a graphical editor in which you create a robot. Second, it allows you to create a complete simulated world. You can place objects from a shared database, or load an existing world. Place your robot inside, start the simulation, and move your robot around.
Source: Gazebo Documentation
Third, it allows to export your robot and world files to common data formats so that they can run with other software. These common formats are:
- URDF: XML file format for detailed modelling of a robot (static structure, joints, sensors, collision and inertia model)
- XACRO: XML macro language, can be used to define less verbose URDF models
- SDF: XML file format for describing a robot simulation, it supersedes the URDF format
The Robotic Operating System is a powerful, coherent tool suite for all aspects of designing and operating a robot system. This article focused the operational learnings. We learned about the core concepts of ROS: Nodes are programs joined by TCP/IP connections that exchange messages asynchronously via topics or synchronously via messages. Information is strictly based on built-in or user-defined datatypes. A ROS system can be explored with helpful CLI tools or graphical tools: See the list of topics, browse messages, or send messages directly. With this understanding, we can continue the exploration of ROS and start to create our own project.