Mastering ROS for Robotics Programming, Third edition E-Book

Lentin Joseph

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 563

Veröffentlichungsjahr: 2021

Beschreibung

The Robot Operating System (ROS) is a software framework used for programming complex robots. ROS enables you to develop software for building complex robots without writing code from scratch, saving valuable development time. Mastering ROS for Robotics Programming provides complete coverage of the advanced concepts using easy-to-understand, practical examples and step-by-step explanations of essential concepts that you can apply to your ROS robotics projects.
The book begins by helping you get to grips with the basic concepts necessary for programming robots with ROS. You'll then discover how to develop a robot simulation, as well as an actual robot, and understand how to apply high-level capabilities such as navigation and manipulation from scratch. As you advance, you'll learn how to create ROS controllers and plugins and explore ROS's industrial applications and how it interacts with aerial robots. Finally, you'll discover best practices and methods for working with ROS efficiently.
By the end of this ROS book, you'll have learned how to create various applications in ROS and build your first ROS robot.

Leseprobe

Mastering ROS for Robotics Programming

Third Edition

Best practices and troubleshooting solutions when working with ROS

Lentin Joseph

Jonathan Cacace

BIRMINGHAM—MUMBAI

Mastering ROS for Robotics Programming Third Edition

Copyright © 2021 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author(s), nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Wilson D’souza

Publishing Product Manager: Meeta Rajani

Senior Editor: Arun Nadar

Content Development Editor: Yasir Ali Khan

Technical Editor: Shruthi Shetty

Copy Editor: Safis Editing

Project Coordinator: Ajesh Devavaram

Proofreader: Safis Editing

Indexer: Manju Arasan

Production Designer: Alishon Mendonca

First published: December 2015

Second edition: February 2018

Third edition: September 2021

Production reference: 1230821

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80107-102-4

www.packt.com

We would like to give special thanks to Mr. Franz Pucher for contributing to Chapter 11, Building and Interfacing Differential Drive Mobile Robot Hardware in ROS, of this book.

Contributors

About the authors

Lentin Joseph is an author, roboticist, and robotics entrepreneur from India. He runs a robotics software company called Qbotics Labs in Kochi, Kerala. He has 10 years of experience in the robotics domain, primarily with ROS, OpenCV, and PCL. He has authored other books on ROS, namely Learning Robotics Using Python, first and second edition, Mastering ROS for Robotics Programming, first and second edition, ROS Robotics Projects, first and second edition, and ROS Learning Path and Robot Operating System for Absolute Beginners. He pursued his master’s in robotics and automation in India and also has worked at the Robotics Institute, CMU, USA. He is also a TEDx speaker.

I would like to dedicate this book to my parents (Jancy Joseph and CG Joseph) and my wife (Aleena Johny).

Jonathan Cacace was born in Naples, Italy, on December 13, 1987. He received a master’s degree in computer science from the University of Naples Federico II in 2012 and a Ph.D. degree in robotics in 2016 from the same institution. Currently, he is an assistant professor at the PRISMA Lab (Projects of Robotics for Industry and Services, Mechatronics and Automation Laboratory) at the University of Naples Federico II, where he is involved in several research projects in the fields of human-robot interaction in industry 4.0 and the autonomous control of UAVs for inspection, maintenance, and robotic manipulation.

I would like to dedicate this book to my family.

About the reviewers

Nick Rotella earned his B.Sc. degree in mechanical engineering from the Cooper Union, followed by his M.Sc. and Ph.D. degrees in computer science from the University of Southern California. As a roboticist, Nick considers himself to be a well-rounded scientist, developer, and engineer. While his Ph.D. thesis focused heavily on model-based motion planning and controls for humanoid robots, he has also worked on autonomous applications in the marine, drone, automotive, mining, and logistics spaces. His experience in controls is based on a deep theoretical understanding of dynamics, estimation, and trajectory generation; Nick has written software at all levels of autonomous system stacks for high-performance controls.

Prateek Nagras is the founder of TechnoYantra (https://www.technoyantra.com/), a service-based robotics start-up based in Pune, India.

He is an engineer who studied instrumentation and control engineering at VIT, Pune, and mechatronics with a specialization in robotics at FH Aachen in Germany.

Having gained valuable experience as a robotics engineer in Germany and Austria, he decided to come back to India and started TechnoYantra in December 2019.

TechnoYantra specializes in providing custom robotic solutions to clients in the automobile, health, industrial, and agricultural sectors in the US, Germany, the Netherlands, Saudi Arabia, Singapore, and more.

When Prateek is not building robots, you can find him playing football or watching sports.

Table of Contents

Preface

Section 1 – ROS Programming Essentials

Chapter 1: Introduction to ROS

Technical requirements

Why should we use ROS?

Understanding the ROS filesystem level

ROS packages

ROS metapackages

ROS messages

The ROS services

Understanding the ROS computation graph level

ROS nodes

ROS messages

ROS topics

ROS services

ROS bagfiles

The ROS master

Using the ROS parameter

ROS community level

Prerequisites for starting with ROS

ROS distributions

Running the ROS master and the ROS parameter server

Summary

Questions

Chapter 2: Getting Started with ROS Programming

Technical requirements

Creating a ROS package

Working with ROS topics

Creating ROS nodes

Building the nodes

Adding custom .msg and .srv files

Working with ROS services

Working with ROS actionlib

Building the ROS action server and client

Creating launch files

Applications of topics, services, and actionlib

Summary

Questions

Section 2 – ROS Robot Simulation

Chapter 3: Working with ROS for 3D Modeling

Technical requirements

ROS packages for robot modeling

Understanding robot modeling using URDF

Creating the ROS package for the robot description

Creating our first URDF model

Explaining the URDF file

Visualizing the 3D robot model in RViz

Interacting with pan-and-tilt joints

Adding physical and collision properties to a URDF model

Understanding robot modeling using xacro

Using properties

Using the math expression

Converting xacro to URDF

Creating the robot description for a seven-DOF robot manipulator

Arm specification

Explaining the xacro model of the seven-DOF arm

Using constants

Using macro

Including other xacro files

Using meshes in the link

Working with the robot gripper

Viewing the seven-DOF arm in RViz

Creating a robot model for the differential drive mobile robot

Summary

Questions

Chapter 4: Simulating Robots Using ROS and Gazebo

Technical requirements

Simulating the robotic arm using Gazebo and ROS

Creating the robotic arm simulation model for Gazebo

Adding colors and textures to the Gazebo robot model

Adding transmission tags to actuate the model

Adding the gazebo_ros_control plugin

Adding a 3D vision sensor to Gazebo

Simulating the robotic arm with Xtion Pro

Visualizing the 3D sensor data

Moving the robot joints using ROS controllers in Gazebo

Understanding the ros_control packages

Different types of ROS controllers and hardware interfaces

How the ROS controller interacts with Gazebo

Interfacing the joint state controllers and joint position controllers with the arm

Launching the ROS controllers with Gazebo

Moving the robot joints

Simulating a differential wheeled robot in Gazebo

Adding the laser scanner to Gazebo

Moving the mobile robot in Gazebo

Adding joint state publishers to the launch file

Adding the ROS teleop node

Questions

Summary

Chapter 5: Simulating Robots Using ROS, CoppeliaSim, and Webots

Technical requirements

Setting up CoppeliaSim with ROS

Understanding the RosInterface plugin

Working with ROS messages

Simulating a robotic arm using CoppeliaSim and ROS

Adding the ROS interface to CoppeliaSim joint controllers

Setting up Webots with ROS

Introduction to the Webots simulator

Simulating a mobile robot with Webots

Writing your first controller

Simulating the robotic arm using Webots and ROS

Writing a teleop node using webots_ros

Starting Webots with a launch file

Summary

Questions

Chapter 6: Using the ROS MoveIt! and Navigation Stack

Technical requirements

The MoveIt! architecture

The move_group node

Motion planning using MoveIt!

Motion-planning request adapters

MoveIt! planning scene

MoveIt! kinematics handling

MoveIt! collision checking

Generating a MoveIt! configuration package using the Setup Assistant tool

Step 1 – Launching the Setup Assistant tool

Step 2 – Generating a self-collision matrix

Step 3 – Adding virtual joints

Step 4 – Adding planning groups

Step 5 – Adding the robot poses

Step 6 – Setting up the robot end effector

Step 7 – Adding passive joints

Step 8 – Author information

Step 9 – Generating configuration files

Motion planning of a robot in RViz using the MoveIt! configuration package

Using the RViz MotionPlanning plugin

Interfacing the MoveIt! configuration package to Gazebo

Understanding the ROS Navigation stack

ROS Navigation hardware requirements

Working with Navigation packages

Workings of the Navigation stack

Building a map using SLAM

Creating a launch file for gmapping

Running SLAM on the differential drive robot

Implementing autonomous navigation using amcl and a static map

Creating an amcl launch file

Summary

Questions

Chapter 7: Exploring the Advanced Capabilities of ROS MoveIt!

Technical requirements

Motion planning using the move_group C++ interface

Motion planning a random path using MoveIt! C++ APIs

Motion planning a custom path using MoveIt! C++ APIs

Collision checking with a robot arm using MoveIt!

Working with perception using MoveIt! and Gazebo

Performing object manipulation with MoveIt!

Working with a robot pick-and-place task using MoveIt!

Pick-and-place actions in Gazebo and real robots

Understanding DYNAMIXEL ROS servo controllers for robot hardware interfacing

DYNAMIXEL servos

DYNAMIXEL-ROS interface

Interfacing a 7-DOF DYNAMIXEL-based robotic arm with ROS MoveIt!

Creating a controller package for a COOL arm robot

MoveIt! configuration of the COOL arm

Summary

Questions

Chapter 8: ROS for Aerial Robots

Technical requirements

Using aerial robots

UAV hardware

Pixhawk autopilot

Using the PX4 flight control stack

PX4 firmware architecture

PX4 SITL

PC/autopilot communication

The mavros ROS package

Writing a ROS-PX4 application

Writing a trajectory streamer

External pose estimation for PX4

Using the RotorS simulation framework

Installing RotorS

RotorS packages

Creating a new UAV model

Interacting with RotorS motor models

Summary

Questions

Section 3 – ROS Robot Hardware Prototyping

Chapter 9: Interfacing I/O Board Sensors and Actuators to ROS

Technical requirements:

Understanding the Arduino-ROS interface

What is the Arduino-ROS interface?

Understanding the rosserial package in ROS

Understanding ROS node APIs in Arduino

ROS-Arduino Publisher and Subscriber example

Arduino-ROS example – blinking an LED with a push button

Arduino-ROS example – Accelerometer ADXL 335

Arduino-ROS example – ultrasonic distance sensor

Arduino-ROS example – odometry data publisher

Interfacing non-Arduino boards to ROS

Setting up the Odroid-C4, Raspberry Pi 4, and Jetson Nano for installing ROS

Blinking the LED using ROS on the Raspberry Pi 4

A push button and a blinking LED using ROS on the Raspberry Pi 2

Running examples on the Raspberry Pi 4

Interfacing DYNAMIXEL actuators to ROS

Summary

Questions

Chapter 10: Programming Vision Sensors Using ROS, OpenCV, and PCL

Technical requirements

Understanding ROS – OpenCV interfacing packages

Understanding ROS – PCL interfacing packages

Installing ROS perception

Interfacing USB webcams in ROS

Working with ROS camera calibration

Converting images between ROS and OpenCV using cv_bridge

Interfacing Kinect and Asus Xtion Pro with ROS

Interfacing the Intel RealSense camera with ROS

Converting point cloud to a laser scan

Interfacing Hokuyo lasers with ROS

Interfacing RPLIDAR and YDLIDAR with ROS

Working with point cloud data

How to publish a point cloud

How to subscribe and process a point cloud

Reading and publishing a point cloud from a PCD file

Summary

Questions

Chapter 11: Building and Interfacing Differential Drive Mobile Robot Hardware in ROS

Technical requirements

Software requirements

Network setup

Hardware requirements

Introduction to the Remo robot – a DIY autonomous mobile robot

Remo hardware components

Software requirements for the ROS Navigation Stack

Developing a low-level controller and a high-level ROS Control hardware interface for a differential drive robot

Implementing the low-level base controller for Remo

ROS Control high-level hardware interface for a differential drive robot

Overview of ROS nodes and topics for the Remo robot

Configuring and working with the Navigation Stack

Configuring the gmapping node and creating a map

Working with the gmapping node

Configuring the move_base node

Configuring the AMCL node

AMCL planning

Working with Remo robot in simulation

Summary

Questions

Section 4 – Advanced ROS Programming

Chapter 12: Working with pluginlib, nodelets, and Gazebo Plugins

Technical requirements

Understanding pluginlib

Implementing a calculator plugin using pluginlib

Understanding ROS nodelets

Implementing a sample nodelet

Understanding and creating a Gazebo plugin

Creating a basic world plugin

Summary

Questions

Chapter 13: Writing ROS Controllers and Visualization Plugins

Technical requirements

Understanding ros_control packages

The controller_interface package

Writing a basic joint controller in ROS

Step 1 – creating the controller package

Step 2 – creating the controller header file

Step 3 – creating the controller source file

Step 4 – detailed explanation of the controller source file

Step 5 – creating the plugin description file

Step 6 – updating package.xml

Step 7 – updating CMakeLists.txt

Step 8 – building the controller

Step 9 – writing the controller configuration file

Step 10 – writing the launch file for the controller

Step 11 – running the controller along with the seven-DOF arm in Gazebo

Understanding the RViz tool and its plugins

The Displays panel

The RViz toolbar

The Views panel

The Time panel

Dockable panels

Writing an RViz plugin for teleoperation

The methodology of building a RViz plugin

Summary

Questions

Chapter 14: Using ROS in MATLAB and Simulink

Technical requirements

Getting started with MATLAB

Getting started with ROS Toolbox and MATLAB

Starting with ROS topics and MATLAB callback functions

Developing a robotic application using MATLAB and Gazebo

Getting started with ROS and Simulink

Creating a wave signal integrator in Simulink

Publishing a ROS message in Simulink

Subscribing to a ROS topic in Simulink

Developing a simple control system in Simulink

Configuring the Simulink model

Summary

Questions

Chapter 15: ROS for Industrial Robots

Technical requirements

Understanding ROS-Industrial packages

Goals of ROS-Industrial

ROS-Industrial – a brief history

Installing ROS-Industrial packages

Block diagram of ROS-Industrial packages

Creating a URDF for an industrial robot

Creating the MoveIt configuration for an industrial robot

Updating the MoveIt configuration files

Installing ROS-Industrial packages for Universal Robots arms

Installing the ROS interface for Universal Robots

Understanding the MoveIt configuration of a Universal Robots arm

Getting started with real Universal Robots hardware and ROS-I

Working with MoveIt configuration for ABB robots

Understanding the ROS-Industrial robot support packages

The ROS-Industrial robot client package

Designing industrial robot client nodes

The ROS-Industrial robot driver package

Understanding the MoveIt IKFast plugin

Creating the MoveIt IKFast plugin for the ABB IRB 6640 robot

Prerequisites for developing the MoveIt IKFast plugin

The OpenRave and IKFast modules

MoveIt IKFast

Installing the MoveIt IKFast package

Installing OpenRave on Ubuntu 20.04

Creating the COLLADA file of a robot to work with OpenRave

Generating the IKFast CPP file for the IRB 6640 robot

Creating the MoveIt IKFast plugin

Summary

Questions

Chapter 16: Troubleshooting and Best Practices in ROS

Setting up Visual Studio Code with ROS

Installing/uninstalling Visual Studio Code

Getting started with Visual Studio Code

Installing new Visual Studio Code extensions

Getting started with the Visual Studio Code ROS extension

Inspecting and building the ROS workspace

Managing ROS packages using Visual Studio Code

Visualizing the preview of a URDF file

Best practices in ROS

ROS C++ coding style guide

Best coding practices for the ROS package

Important troubleshooting tips in ROS

Using roswtf

Summary

Questions

Why subscribe?

Other Books You May Enjoy

Preface

The Robot Operating System (ROS) is a globally used robotics middleware that helps developers to program robotic applications and is currently adopted by robotics companies, research centers, and universities to program advanced robots. Mastering ROS for Robotics Programming, Third Edition presents advanced concepts of the ROS framework and is particularly suitable for users who are already familiar with the basic concepts of ROS. However, a brief introduction to the basic ROS concepts is provided in the first chapter in order to help new developers start with the examples in the book.

You will be guided through the creation, the modeling and design, of new robots, as well as simulating and interfacing them with the ROS framework. You will use advanced simulation software to use ROS tools that allow robot navigation, manipulation, and sensor elaboration. Finally, you will learn how to handle important concepts such as ROS low-level controllers, nodelets, and plugins.

You can work with almost all of the examples of the book using only a standard computer without any special hardware requirements. However, additional hardware components will be used in some chapters of the book to discuss how to use ROS with external sensors, actuators, and I/O boards.

The book is organized as follows: after an introduction to the basic concepts of ROS, how to model and simulate a robot is discussed. Gazebo, CoppeliaSim, and the Webots software simulator will be used to control and interact with the modeled robot. These simulators will be used to connect to robots with the MoveIt! and navigation ROS packages. ROS plugins, controllers, and nodelets are then discussed. Finally, the book discusses how to connect MATLAB and Simulink with ROS.

Who this book is for

This book is meant to be used by passionate robotics developers or researchers who want to fully exploit the features of ROS. The book is also good for users who are already familiar with typical robotics applications or who want to start learning how to develop in the world of ROS in an advanced manner, learning how to model, build, and control their robots. Basic knowledge of GNU/Linux and C++ programming is strongly recommended if you want to easily comprehend the contents of the book.

What this book covers

Chapter 1, Introduction to ROS, gives you an understanding of the core underlying concepts of ROS.

Chapter 2, Getting Started with ROS Programming, explains how to work with ROS packages.

Chapter 3, Working with ROS for 3D Modeling, discusses the design of two robots; one is a seven Degrees of Freedom (DOF) manipulator, and the other is a differential drive robot.

Chapter 4, Simulating Robots Using ROS and Gazebo, discusses the simulation of a seven-DOF arm, differential wheeled robots, and ROS controllers that help control robot joints in Gazebo.

Chapter 5, Simulating Robots Using ROS, CoppeliaSim and Webots, introduces the CoppeliaSim and Webots simulators, showing how to simulate and control different types of robots.

Chapter 6, Using the ROS MoveIt! and Navigation Stack On, covers out-of-the-box functionalities such as robot manipulation and autonomous navigation using ROS MoveIt! and the navigation stack.

Chapter 7, Exploring the Advanced Capabilities of ROS-MoveIt!, discusses the capabilities of MoveIt!, such as collision avoidance, perception using 3D sensors, grasping, picking, and placing. After that, we will see how to interface robotic manipulator hardware with MoveIt!.

Chapter 8, ROS for Aerial Robots, discusses how to simulate and control aerial robots with ROS, considering the particular case of quadcopters.

Chapter 9, Interfacing I/O Boards, Sensors, and Actuators to ROS, discusses interfacing some hardware components, such as sensors and actuators, with ROS. We will look at the interfacing of sensors using I/O boards, such as Arduino or Raspberry Pi, with ROS.

Chapter 10, Programming Vision Sensors Using ROS, OpenCV, and PCL, discusses how to interface various vision sensors with ROS and program them using libraries such as Open Source Computer Vision (OpenCV) and Point Cloud Library (PCL).

Chapter 11, Building and Interfacing Differential Drive Mobile Robot Hardware in ROS, helps you to build autonomous mobile robot hardware with differential drive configuration and interface it with ROS. This chapter aims to give you an understanding of building a custom mobile robot and interfacing it with ROS.

Chapter 12, Working with pluginlib, Nodelets, and Gazebo Plugins, shows some of the advanced concepts in ROS, such as ROS pluginlib, nodelets, and Gazebo plugins. We will discuss the functionalities and application of each concept and will practice one example to demonstrate their workings.

Chapter 13, Writing ROS Controllers and Visualization Plugins, shows how to write and run a basic ROS controller. We will also see how to create a plugin for RViz.

Chapter 14, Using ROS in MATLAB and Simulink, discusses how to connect MATLAB and Simulink with ROS.

Chapter 15, ROS for Industrial Robots, helps you understand and install ROS-Industrial packages in ROS. We will see how to develop a MoveIt! IKFast plugin for an industrial robot.

Chapter 16, Troubleshooting and Best Practices in ROS, discusses how to set up a ROS development environment in Eclipse IDE, best practices in ROS, and troubleshooting tips in ROS.

To get the most out of this book

In order to run the examples in this book, you need a standard PC running a Linux OS. Ubuntu 20.04 is the suggested Linux distribution, but Debian 10 is supported as well. The suggested PC configuration requires at least 4 GB of RAM and a modern processor to execute Gazebo simulations and image processing algorithms. You can even work in a virtual environment setup, installing the Linux OS on a virtual machine and using VirtualBox or VMware hosted on a Windows system. The disadvantage of this choice is that more computational power is needed to work with the examples and you could face issues when interfacing ROS with real hardware. The software needed to follow the book is ROS and Noetic Ninjemys. The additional software required is the CoppeliaSim and Webots simulators, Git, MATLAB, and Simulink. Finally, some chapters help you to interface ROS with commercial hardware such as I/O boards (Arduino, ODROID, and Raspberry Pi computers), vision sensors (Intel RealSense), and actuators. These are special hardware components that must be bought to run some examples of the book but are not strictly required to learn ROS.

Download the example code files

You can download the example code files for this book from GitHub at https://github.com/PacktPublishing/Mastering-ROS-for-Robotics-Programming-Third-edition. In case there's an update to the code, it will be updated on the existing GitHub repository.

We also have other code bundles from our rich catalogue of books and videos available at https://github.com/PacktPublishing/. Check them out!

Code in Action

The Code in Action videos for this book can be viewed at https://bit.ly/3iYZnGH.

Download the color images

We also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it here: http://www.packtpub.com/sites/default/files/downloads/9781801071024_ColorImages.pdf.

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: "We are using the catkin build system to build ROS packages."

A block of code is set as follows:

void number_callback(const std_msgs::Int32::ConstPtr& msg) {

ROS_INFO("Received [%d]",msg->data);

}

When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:

ssh nvidia@nano_ip_adress

password is nano

Any command-line input or output is written as follows:

$ mkdir css

$ cd css

Bold: Indicates a new term, an important word, or words that you see onscreen. For example, words in menus or dialog boxes appear in the text like this. Here is an example: "To create a new simulation, use the top bar menu and select Wizards | New Project Directory."

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, mention the book title in the subject of your message and email us at [email protected].

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata, selecting your book, clicking on the Errata Submission Form link, and entering the details.

Piracy: If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you've read Mastering ROS for Robotics Programming, Third edition, we'd love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we're delivering excellent quality content.

Section 1 – ROS Programming Essentials

This section discusses the fundamental concepts of ROS in detail. You will get a clear and crisp idea of ROS concepts after this section. These concepts are required to be understood in order to work on the chapters covering advanced concepts of ROS.

This section comprises the following chapters:

Chapter 1, Introduction to ROSChapter 2, Getting Started with ROS Programming

Chapter 1: Introduction to ROS

The first two chapters of this book will introduce basic ROS concepts and the ROS package management system in order to approach ROS programming. In this first chapter, we will go through ROS concepts such as the ROS master, the ROS nodes, the ROS parameter server, and ROS messages and services, all while discussing what we need to install ROS and how to get started with the ROS master.

In this chapter, we will cover the following topics:

Why should we learn ROS?Understanding the ROS filesystem level.Understanding ROS computation graph level.ROS community level.

Technical requirements

To follow this chapter, the only thing you need is a standard computer running Ubuntu 20.04 LTS or a Debian 10 GNU/Linux distribution.

Why should we use ROS?

Robot Operating System (ROS) is a flexible framework that provides various tools and libraries for writing robotic software. It offers several powerful features to help developers in tasks such as message passing, distributed computing, code reusing, and implementing state-of-the-art algorithms for robotic applications. The ROS project was started in 2007 by Morgan Quigley and its development continued at Willow Garage, a robotics research lab for developing hardware and open source software for robots. The goal of ROS was to establish a standard way to program robots while offering off-the-shelf software components that can be easily integrated with custom robotic applications. There are many reasons to choose ROS as a programming framework, and some of them are as follows:

High-end capabilities: ROS comes with ready-to-use functionalities. For example, the Simultaneous Localization and Mapping (SLAM) and Adaptive Monte Carlo Localization (AMCL) packages in ROS can be used for having autonomous navigation in mobile robots, while the MoveIt package can be used for motion planning for robot manipulators. These capabilities can directly be used in our robot software without any hassle. In several cases, these packages are enough for having core robotics tasks on different platforms. Also, these capabilities are highly configurable; we can fine-tune each one using various parameters.Tons of tools: The ROS ecosystem is packed with tons of tools for debugging, visualizing, and having a simulation. The tools, such as rqt_gui, RViz, and Gazebo, are some of the strongest open source tools for debugging, visualization, and simulation. A software framework that has this many tools is very rare.Support for high-end sensors and actuators: ROS allows us to use different device drivers and the interface packages of various sensors and actuators in robotics. Such high-end sensors include 3D LIDAR, laser scanners, depth sensors, actuators, and more. We can interface these components with ROS without any hassle.Inter-platform operability: The ROS message-passing middleware allows communication between different programs. In ROS, this middleware is known as nodes. These nodes can be programmed in any language that has ROS client libraries. We can write high-haveance nodes in C++ or C and other nodes in Python or Java. Modularity: One of the issues that can occur in most standalone robotic applications is that if any of the threads of the main code crash, the entire robot application can stop. In ROS, the situation is different; we are writing different nodes for each process, and if one node crashes, the system can still work. Concurrent resource handling: Handling a hardware resource via more than two processes is always a headache. Imagine that we want to process an image from a camera for face detection and motion detection; we can either write the code as a single entity that can do both, or we can write a single-threaded piece of code for concurrency. If we want to add more than two features to threads, the application behavior will become complex and difficult to debug. But in ROS, we can access devices using ROS topics from the ROS drivers. Any number of ROS nodes can subscribe to the image message from the ROS camera driver, and each node can have different functionalities. This can reduce the complexity in computation and also increase the debugging ability of the entire system.

The ROS community is growing very fast, and there are many users and developers worldwide. Most high-end robotics companies are now porting their software to ROS. This trend is also visible in industrial robotics, in which companies are switching from proprietary robotic applications to ROS.

Now that we know why it is convenient to study ROS, we can start introducing its core concepts. There are mainly three levels in ROS: the filesystem level, the computation graph level, and the community level. We will briefly have a look at each level.

Understanding the ROS filesystem level

ROS is more than a development framework. We can refer to ROS as a meta-OS, since it offers not only tools and libraries but even OS-like functions, such as hardware abstraction, package management, and a developer toolchain. Like a real operating system, ROS files are organized on the hard disk in a particular manner, as depicted in the following diagram:

Figure 1.1 – ROS filesystem level

Here are the explanations for each block in the filesystem:

Packages: The ROS packages are a central element of the ROS software. They contain one or more ROS programs (nodes), libraries, configuration files, and so on, which are organized together as a single unit. Packages are the atomic build and release items in the ROS software.Package manifest: The package manifest file is inside a package and contains information about the package, author, license, dependencies, compilation flags, and so on. The package.xml file inside the ROS package is the manifest file of that package.Metapackages: The term metapackage refers to one or more related packages that can be loosely grouped. In principle, metapackages are virtual packages that don't contain any source code or typical files usually found in packages.Metapackages manifest: The metapackage manifest is similar to the package manifest, with the difference being that it might include packages inside it as runtime dependencies and declare an export tag.Messages (.msg): We can define a custom message inside the msg folder inside a package (my_package/msg/MyMessageType.msg). The extension of the message file is .msg.Services (.srv): The reply and request data types can be defined inside the srv folder inside the package (my_package/srv/MyServiceType.srv).Repositories: Most of the ROS packages are maintained using a Version Control System (VCS) such as Git, Subversion (SVN), or Mercurial (hg). A set of files placed on a VCS represents a repository.

The following screenshot gives you an idea of the files and folders of a package that we are going to create in the upcoming sections:

Figure 1.2 – List of files inside the exercise package

The goal of all the files and directories included in a ROS package will be discussed next.

ROS packages

The typical structure of a ROS package is shown here:

Figure 1.3 – Structure of a typical C++ ROS package

Let's discuss the use of each folder:

config: All configuration files that are used in this ROS package are kept in this folder. This folder is created by the user and it is a common practice to name the folder config as this is where we keep the configuration files.include/package_name: This folder consists of headers and libraries that we need to use inside the package.script: This folder contains executable Python scripts. In the block diagram, we can see two example scripts.src: This folder stores the C++ source codes.launch: This folder contains the launch files that are used to launch one or more ROS nodes.msg: This folder contains custom message definitions.srv: This folder contains the services definitions.action: This folder contains the action files. We will learn more about these kinds of files in the next chapter.package.xml: This is the package manifest file of this package.CMakeLists.txt: This file contains the directives to compile the package.

We need to know some commands for creating, modifying, and working with ROS packages. Here are some of the commands we can use to work with ROS packages:

catkin_create_pkg: This command is used to create a new package.rospack: This command is used to get information about the package in the filesystem.catkin_make: This command is used to build the packages in the workspace.rosdep: This command will install the system dependencies required for this package.

To work with packages, ROS provides a bash-like command called rosbash (http://wiki.ros.org/rosbash), which can be used to navigate and manipulate the ROS package. Here are some of the rosbash commands:

roscd: This command is used to change the current directory using a package name, stack name, or a special location. If we give the argument a package name, it will switch to that package folder.roscp: This command is used to copy a file from a package.rosed: This command is used to edit a file using the vim editor.rosrun: This command is used to run an executable inside a package.

The definition of package.xml in a typical package is shown in the following screenshot:


Figure 1.4 – Structure of package.xml

The package.xml file also contains information about the compilation. The <build_depend></build_depend> tag includes the packages that are necessary for building the source code of the package. The packages inside the <run_depend></run_depend> tags are necessary for running the package node at runtime.

ROS metapackages

Metapackages are specialized packages that require only one file; that is, a package.xml file.

Metapackages simply group a set of multiple packages as a single logical package. In the package.xml file, the metapackage contains an export tag, as shown here:

  <export>

    <metapackage/>

  </export>  

Also, in metapackages, there are no <buildtool_depend> dependencies for catkin; there are only <run_depend> dependencies, which are the packages that are grouped inside the metapackage.

The ROS navigation stack is a good example of somewhere that contains metapackages. If ROS and its navigation package are installed, we can try using the following command by switching to the navigation metapackage folder:

roscd navigation  

Open package.xml using your favorite text editor (gedit, in the following case):

gedit package.xml  

This is a lengthy file; here is a stripped-down version of it:

Figure 1.5 – Structure of the package.xml metapackage

This file contains several pieces of information about the package, such as a brief description, its dependencies, and the package version.

ROS messages

ROS nodes can write or read data of various types. These different types of data are described using a simplified message description language, also called ROS messages. These data type descriptions can be used to generate source code for the appropriate message type in different target languages.

Even though the ROS framework provides a large set of robotic-specific messages that have already been implemented, developers can define their own message type inside their nodes.

The message definition can consist of two types: fields and constants. The field is split into field types and field names. The field type is the data type of the transmitting message, while the field name is the name of it.

Here is an example of message definitions:

int32 number

string name

float32 speed

Here, the first part is the field type and the second is the field name. The field type is the data type, and the field name can be used to access the value from the message. For example, we can use msg.number to access the value of the number from the message.

Here is a table showing some of the built-in field types that we can use in our message:

ROS provides a set of complex and more structured message files that are designed to cover a specific application's necessity, such as exchanging common geometrical (geometry_msgs) or sensor (sensor_msgs) information. These messages are composed of different primitive types. A special type of ROS message is called a message header. This header can carry information, such as time, frame of reference or frame_id, and sequence number. Using the header, we will get numbered messages and more clarity about which component is sending the current message. The header information is mainly used to send data such as robot joint transforms. Here is the definition of the header:

uint32 seq

time stamp

string frame_id

The rosmsg command tool can be used to inspect the message header and the field types. The following command helps view the message header of a particular message:

rosmsg show std_msgs/Header  

This will give you an output like the preceding example's message header. We will look at the rosmsg command and how to work with custom message definitions later in this chapter.

The ROS services

The ROS services are a type of request/response communication between ROS nodes. One node will send a request and wait until it gets a response from the other.

Similar to the message definitions when using the .msg file, we must define the service definition in another file called .srv, which must be kept inside the srv subdirectory of the package.

An example service description format is as follows:

#Request message type

string req

---

#Response message type

string res

The first section is the message type of the request, which is separated by ---, while the next section contains the message type of the response. In these examples, both Request and Response are strings.

In the upcoming sections, we will look at how to work with ROS services.

Understanding the ROS computation graph level

Computation in ROS is done using a network of ROS nodes. This computation network is called the computation graph. The main concepts in the computation graph are ROS nodes, master, parameter server, messages, topics, services, and bags. Each concept in the graph is contributed to this graph in different ways.

The ROS communication-related packages, including core client libraries, such as roscpp and rospython, and the implementation of concepts, such as topics, nodes, parameters, and services, are included in a stack called ros_comm (http://wiki.ros.org/ros_comm).

This stack also consists of tools such as rostopic, rosparam, rosservice, and rosnode to introspect the preceding concepts.

The ros_comm stack contains the ROS communication middleware packages, and these packages are collectively called the ROS graph layer:

Figure 1.6 – Structure of the ROS graph layer

Some new elements of the ROS graph are as follows:

Nodes: Nodes are the processes that have computation. Each ROS node is written using ROS client libraries. Using client library APIs, we can implement different ROS functionalities, such as the communication methods between nodes, which is particularly useful when the different nodes of our robot must exchange information between them. One of the aims of ROS nodes is to build simple processes rather than a large process with all the desired functionalities. Being simple structures, ROS nodes are easy to debug.Master: The ROS master provides the name registration and lookup processes for the rest of the nodes. Nodes will not be able to find each other, exchange messages, or invoke services without a ROS master. In a distributed system, we should run the master on one computer; then, the other remote nodes can find each other by communicating with this master.Parameter server: The parameter server allows you to store data in a central location. All the nodes can access and modify these values. The parameter server is part of the ROS master.Topics: Each message in ROS is transported using named buses called topics. When a node sends a message through a topic, then we can say the node is publishing a topic. When a node receives a message through a topic, then we can say that the node is subscribing to a topic. The publishing node and subscribing node are not aware of each other's existence. We can even subscribe to a topic that might not have any publisher. In short, the production of information and its consumption are decoupled. Each topic has a unique name, and any node can access this topic and send data through it so long as they have the right message type.Logging: ROS provides a logging system for storing data, such as sensor data, which can be difficult to collect but is necessary for developing and testing robot algorithms. These are known as bagfiles. Bagfiles are very useful features when we're working with complex robot mechanisms.

The following graph shows how the nodes communicate with each other using topics:

Figure 1.7 – Graph of communication between nodes using topics

As you can see, the topics are represented by rectangles, while the nodes are represented by ellipses. The messages and parameters are not included in this graph. These kinds of graphs can be generated using a tool called rqt_graph (http://wiki.ros.org/rqt_graph).

ROS nodes

ROS nodes have computations using ROS client libraries such as roscpp and rospy.

A robot might contain many nodes; for example, one node processes camera images, one node handles serial data from the robot, one node can be used to compute odometry, and so on.

Using nodes can make the system fault-tolerant. Even if a node crashes, an entire robot system can still work. Nodes also reduce complexity and increase debug-ability compared to monolithic code because each node is handling only a single function.

All running nodes should have a name assigned to help us identify them. For example, /camera_node could be the name of a node that is broadcasting camera images.

There is a rosbash tool for introspecting ROS nodes. The rosnode command can be used to gather information about an ROS node. Here are the usages of rosnode:

rosnode info [node_name]: This will print out information about the node.rosnode kill [node_name]: This will kill a running node.rosnode list: This will list the running nodes.rosnode machine [machine_name]: This will list the nodes that are running on a particular machine or a list of machines.rosnode ping: This will check the connectivity of a node.rosnode cleanup: This will purge the registration of unreachable nodes.

Next, we will look at some example nodes that use the roscpp client and discuss how ROS nodes that use functionalities such ROS topics, service, messages, and actionlib work.

ROS messages

As we discussed earlier, messages are simple data structures that contain field types. ROS messages support standard primitive data types and arrays of primitive types.

We can access a message definition using the following method. For example, to access std_msgs/msg/String.msg when we are using the roscpp client, we must include std_msgs/String.h for the string message definition.

In addition to the message data type, ROS uses an MD5 checksum comparison to confirm whether the publisher and subscriber exchange the same message data types.

ROS has a built-in tool called rosmsg for gathering information about ROS messages. Here are some parameters that are used along with rosmsg:

rosmsg show [message_type]: This shows the message's description.rosmsg list: This lists all messages.rosmsg md5 [message_type]: This displays md5sum of a message.rosmsg package [package_name]: This lists messages in a package.rosmsg packages [package_1] [package_2]: This lists all packages that contain messages.

Now, let's take a look at ROS topics.

ROS topics

Using topics, the ROS communication is unidirectional. Differently, if we want a direct request/response communication, we need to implement ROS services.

The ROS nodes communicate with topics using a TCP/IP-based transport known as TCPROS. This method is the default transport method used in ROS. Another type of communication is UDPROS, which has low latency and loose transport and is only suited for teleoperations.

The ROS topic tool can be used to gather information about ROS topics. Here is the syntax of this command:

rostopic bw /topic: This command will display the bandwidth being used by the given topic.rostopic echo /topic: This command will print the content of the given topic in a human-readable format. Users can use the -p option to print data in CSV format.rostopic find /message_type: This command will find topics using the given message type.rostopic hz /topic: This command will display the publishing rate of the given topic.rostopic info /topic: This command will print information about an active topic.rostopic list: This command will list all the active topics in the ROS system.rostopic pub /topic message_type args: This command can be used to publish a value to a topic with a message type.rostopic type /topic: This will display the message type of the given topic.

Now, let's take a look at ROS services.

ROS services

In ROS services, one node acts as a ROS server in which the service client can request the service from the server. If the server completes the service routine, it will send the results to the service client. For example, consider a node that can provide the sum of two numbers that has been received as input while implementing this functionality through an ROS service. The other nodes of our system might request the sum of two numbers via this service. In this situation, topics are used to stream continuous data flows.

The ROS service definition can be accessed by the following method. For example, my_package/srv/Image.srv can be accessed by my_package/Image.

In ROS services, there is an MD5 checksum that checks in the nodes. If the sum is equal, then only the server responds to the client.

There are two ROS tools for gathering information about the ROS service. The first tool is rossrv, which is similar to rosmsg, and is used to get information about service types. The next command is rosservice, which is used to list and query the running ROS services.

Let's explain how to use the rosservice tool to gather information about the running services:

rosservice call /service args: This tool will call the service using the given arguments.rosservice find service_type: This command will find the services of the given service type.rosservice info /services: This will print information about the given service.rosservice list: This command will list the active services running on the system.rosservice type /service: This command will print the service type of a given service.rosservice uri /service: This tool will print the service's ROSRPC URI.

Now, let's take a look at ROS bagfiles.

ROS bagfiles

The rosbag command is used to work with rosbag files. A bag file in ROS is used for storing ROS message data that's streamed by topics. The .bag extension is used to represent a bag file.

Bag files are created using the rosbag record command, which will subscribe to one or more topics and store the message's data in a file as it's received. This file can play the same topics that they are recorded from, and it can remap the existing topics too.

Here are the commands for recording and playing back a bag file:

rosbag record [topic_1] [topic_2] -o [bag_name]: This command will record the given topics into the bag file provided in the command. We can also record all topics using the -a argument.rosbag play [bag_name]: This will play back the existing bag file.

The full, detailed list of commands can be found by using the following command in a Terminal:

rosbag play -h

There is a GUI tool that we can use to handle how bag files are recorded and played back called rqt_bag. To learn more about rqt_bag, go to https://wiki.ros.org/rqt_bag.

The ROS master

The ROS master is much like a DNS server, in that it associates unique names and IDs to the ROS elements that are active in our system. When any node starts in the ROS system, it will start looking for the ROS master and register the name of the node in it. So, the ROS master has the details of all the nodes currently running on the ROS system. When any of the node's details change, it will generate a callback and update the node with the latest details. These node details are useful for connecting each node.

When a node starts publishing to a topic, the node will give the details of the topic, such as its name and data type, to the ROS master. The ROS master will check whether any other nodes are subscribed to the same topic. If any nodes are subscribed to the same topic, the ROS master will share the node details of the publisher to the subscriber node. After getting the node details, these two nodes will be connected. After connecting to the two nodes, the ROS master has no role in controlling them. We might be able to stop either the publisher node or the subscriber node according to our requirements. If we stop any nodes, they will check in with the ROS master once again. This same method is used for the ROS services.

As we've already stated, the nodes are written using ROS client libraries, such as roscpp and rospy. These clients interact with the ROS master using XML Remote Procedure Call (XMLRPC)-based APIs, which act as the backend of the ROS system APIs.

The ROS_MASTER_URI environment variable contains the IP and port of the ROS master. Using this variable, ROS nodes can locate the ROS master. If this variable is wrong, communication between the nodes will not take place. When we use ROS in a single system, we can use the IP of a localhost or the name localhost itself. But in a distributed network, in which computation is done on different physical computers, we should define ROS_MASTER_URI properly; only then will the remote nodes be able to find each other and communicate with each other. We only need one master in a distributed system, and it should run on a computer in which all the other computers can ping it properly to ensure that remote ROS nodes can access the master.

The following diagram shows how the ROS master interacts with publishing and subscribing nodes, with the publisher node publishing a string type topic with a Hello World message and the subscriber node subscribing to this topic:

Figure 1.8 – Communication between the ROS master and Hello World publisher and subscriber

When the publisher node starts advertising the Hello World message in a particular topic, the ROS master gets the details of the topic and the node. It will check whether any node is subscribing to the same topic. If no nodes are subscribing to the same topic at that time, both nodes will remain unconnected. If the publisher and subscriber nodes run at the same time, the ROS master will exchange the details of the publisher to the subscriber, and they will connect and exchange data through ROS topics.

Using the ROS parameter

When programming a robot, we might have to define robot parameters to tune our control algorithm, such as the robot controller gains P, I, and D of a standard proportional–integral–derivative controller. When the number of parameters increases, we might need to store them as files. In some situations, these parameters must be shared between two or more programs. In this case, ROS provides a parameter server, which is a shared server in which all the ROS nodes can access parameters from this server. A node can read, write, modify, and delete parameter values from the parameter server.

We can store these parameters in a file and load them into the server. The server can store a wide variety of data types and even dictionaries. The programmer can also set the scope of the parameter; that is, whether it can be accessed by only this node or all the nodes.

The parameter server supports the following XMLRPC data types:

32-bit integersBooleansStringsDoublesISO8601 datesListsBase64-encoded binary data

We can also store dictionaries on the parameter server. If the number of parameters is high, we can use a YAML file to save them. Here is an example of the YAML file parameter definitions:

/camera/name : 'nikon'  #string type

/camera/fps : 30     #integer   

/camera/exposure : 1.2  #float  

/camera/active : true  #boolean

The rosparam tool is used to get and set the ROS parameter from the command line. The following are the commands for working with ROS parameters:

rosparam set [parameter_name] [value]: This command will set a value in the given parameter.rosparam get [parameter_name]: This command will retrieve a value from the given parameter.rosparam load [YAML file]: The ROS parameters can be saved into a YAML file. It can load them into the parameter server using this command.rosparam dump [YAML file]: This command will dump the existing ROS parameters into a YAML file.rosparam delete [parameter_name]: This command will delete the given parameter.rosparam list: This command will list existing parameter names.

These parameters can be changed dynamically when you're executing a node that uses these parameters by using the dyamic_reconfigure package (http://wiki.ros.org/dynamic_reconfigure).

ROS community level

These are ROS resources that enable a new community in ROS to exchange software and knowledge. The various resources in these communities are as follows:

Distributions: Similar to the Linux distribution, ROS distributions are a collection of versioned metapackages that we can install. The ROS distributions allow us to easily install and collect ROS software. They also maintain consistent versions across a set of software.Repositories: ROS relies on a federated network of code repositories, where different institutions can develop and release their own robot software components.The ROS Wiki: The ROS community Wiki is the main forum for documenting information about ROS. Anyone can sign up for an account and contribute their own documentation, provide corrections or updates, write tutorials, and more.Bug ticket system: If we find a bug in the existing software or need to add a new feature, we can use this resource.Mailing lists: We can use the ROS-users mailing list to ask questions about ROS software and share program problems with the community.ROS Answers: This website resource helps us ask questions related to ROS. If we post our doubts on this site, other ROS users can see them and provide solutions.Blog: The ROS blog updates with news, photos, and videos related to the ROS community (http://www.ros.org/news).

Now, let's take a look at prerequisites for starting with ROS.

Prerequisites for starting with ROS

Before getting started with ROS and trying the code in this book, the following prerequisites should be met:

Ubuntu 20.04 LTS/Debian 10: ROS is officially supported by the Ubuntu and Debian operating systems. We prefer to stick with the LTS version of Ubuntu; that is, Ubuntu 20.04.ROS noetic desktop full installation: Install the full desktop installation of ROS. The version we prefer is ROS Noetic, which is the latest stable version. The following link provides the installation instructions for the latest ROS distribution: http://wiki.ros.org/noetic/Installation/Ubuntu. Choose the ros-noetic-desktop-full package from the repository list.

Let's see the different versions of ROS framework.

ROS distributions

ROS updates are released with new ROS distributions. A new distribution of ROS is composed of an updated version of its core software and a set of new/updated ROS packages. ROS follows the same release cycle as the Ubuntu Linux distribution: a new version of ROS is released every 6 months. Typically, for each Ubuntu LTS version, an LTS version of ROS is released. Long Term Support (LTS) and means that the released software will be maintained for a long time (5 years in the case of ROS and Ubuntu):

Figure 1.9 – List of recent ROS releases

The tutorials in this book are based on the latest LTS version of ROS, known as ROS Noetic Ninjemys. It represents the thirteenth ROS distribution release. The list of recent ROS distributions is shown in the preceding image.

Running the ROS master and the ROS parameter server

Before running any ROS nodes, we should start the ROS master and the ROS parameter server. We can start the ROS master and the ROS parameter server by using a single command called roscore, which will start the following programs:

ROS masterROS parameter serverrosout logging nodes

The rosout node will collect log messages from other ROS nodes and store them in a log file, and will also re-broadcast the collected log message to another topic. The /rosout topic is published by ROS nodes using ROS client libraries such as roscpp and rospy, and this topic is subscribed by the rosout node, which rebroadcasts the message in another topic called /rosout_agg. This topic contains an aggregate stream of log messages. The roscore command should be run as a prerequisite to running any ROS nodes. The following screenshot shows the messages that are printed when we run the roscore command in a Terminal.

Use the following command to run roscore on a Linux Terminal:

roscore   

After running this command, we will see the following text in the Linux Terminal:

Figure 1.10 – Terminal messages while running the roscore command

The following are explanations of each section when executing roscore in a Terminal:

In section 1, we can see that a log file is created inside the ~/.ros/log folder for collecting logs from ROS nodes. This file can be used for debugging purposes.In section 2, the command starts a ROS launch file called roscore.xml. When a launch file starts, it automatically starts rosmaster and the ROS parameter server. The roslaunch command is a Python script, which can start rosmaster and the ROS parameter server whenever it tries to execute a launch file. This section shows the address of the ROS parameter server within the port.In section 3, we can see parameters such as rosdistro and rosversion being displayed in the Terminal. These parameters are displayed when it executes roscore.xml. We will look at roscore.xml in more detail in the next section.In section 4, we can see that the rosmaster node is being started with ROS_MASTER_URI, which we defined earlier as an environment variable.In section 5, we can see that the rosout node is being started, which will start subscribing to the /rosout topic and rebroadcasting it to /rosout_agg.

The following is the content of roscore.xml:

<launch>

  <group ns="/">

    <param name="rosversion" command="rosversion roslaunch" />

    <param name="rosdistro" command="rosversion -d" />

    <node pkg="rosout" type="rosout" name="rosout" respawn="true"/>

  </group>

</launch>

When the roscore command is executed, initially, the command checks the command-line argument for a new port number for rosmaster. If it gets the port number, it will start listening to the new port number; otherwise, it will use the default port. This port number and the roscore.xml launch file will be passed to the roslaunch system. The roslaunch system is implemented in a Python module; it will parse the port number and launch the roscore.xml file.

In the roscore.xml file, we can see that the ROS parameters and nodes are encapsulated in a group XML tag with a / namespace. The group XML tag indicates that all the nodes inside this tag have the same settings.

The rosversion and rosdistro parameters store the output of the rosversionroslaunch and rosversion-d commands using the command tag, which is a part of the ROS param tag. The command tag will execute the command mentioned in it and store the output of the command in these two parameters.

rosmaster and the parameter server are executed inside roslaunch modules via the ROS_MASTER_URI address. This happens inside the roslaunch Python module. ROS_MASTER_URI is a combination of the IP address and port that rosmaster is going to listen to. The port number can be changed according to the given port number in the roscore command.

Checking the roscore command's output

Let's check out the ROS topics and ROS parameters that are created after running roscore. The following command will list the active topics in the Terminal:

rostopic list  

The list of topics is as follows, as per our discussion of the rosout node's subscribe /rosout topic. This contains all the log messages from the ROS nodes. /rosout_agg will rebroadcast the log messages:

/rosout

/rosout_agg  

The following command lists the parameters that are available when running roscore. The following command is used to list the active ROS parameter:

rosparam list  

These parameters are mentioned here; they provide the ROS distribution name, version, the address of the roslaunch server, and run_id, where run_id is a unique ID associated with a particular run of roscore:

/rosdistro

/roslaunch/uris/host_robot_virtualbox__51189

/rosversion

/run_id

The list of ROS services that's generated when running roscore