Introduction

A robot operating system is a framework for creating robot applications that

allows developers to connect existing solutions to small problems to assemble
complex systems. It is not an actual operating system, but rather a framework
and toolset that provides the functionality of an operating system on a
heterogeneous cluster of computers. Its usefulness is not limited to robots, but
most of the tools provided are focused on manipulating peripheral hardware.
ROS is divided into over 2000 packages, each providing specific functionality.
The number of tools associated with the framework is perhaps its greatest
strength.

ROS logo
ROS provides features such as hardware abstraction, device drivers, inter-
process communication across multiple machines, and tools for testing and
visualization. A key feature of ROS is how software runs and communicates,
allowing you to design complex software without knowing how the particular
hardware works. ROS provides a way to connect networks of processes (nodes)
to a central hub. Nodes can run on multiple devices and can connect to this hub
in different ways. The main way to create a network is to provide requestable
services or define publisher/subscriber connections with other nodes. Both
methods communicate through the specified message type. Some types are
provided in the core package, but message types can be defined in individual
packages.
As a framework, ROS is also the product of trade-offs and prioritizations made
during the design cycle. His focus on large-scale integrated robotics research
will prove useful in a variety of contexts as robotic systems become more
complex. ROS is not an operating system but a meta operating system, which
means it assumes that there is an underlying operating system that will help it
perform its tasks.
The concept of ROS goes far beyond frameworks. Because ROS provides all
the services other operating systems provide, such as hardware abstraction, low-
level device control, implementation of commonly used functions, inter-process
messaging, and package management, the concept operating system above.
ROS is not yet the only framework for robots, not a standalone operating system
or his RTOS, but it seems to be widely used and has a large developer
community.

1
Developing robots with computer brains requires many software tools on the
computer side, including software drivers, third-party computer vision tools,
and simulation tools. The ROS framework collects all these tools and manages
how you develop your robot's code. ROS can be installed on single board
computers (SBCs) at the Raspberry Pi level or higher using Ubuntu/Debian
distributions. However, other platforms are experimental or supported by the
community.

Reasons to use ROS

1. ROS is general
The same basic code and knowledge can be applied to different kinds of
robots, such as robotic arms, drones, and mobile bases. Once you've
learned how the communication between all the nodes of your program is
done, the application is pretty straightforward. If you need to switch to a
completely different robotics project in the future, don't hesitate.

2. ROS packages for everything

ROS is divided into over 2000 packages, each providing specific
functionality. The number of tools associated with the framework is
perhaps its greatest strength.

3. ROS is language-agnostic
You can easily communicate between Python and C++ nodes. This means
a lot of reusability and coworking possibilities. Many libraries can also
use other languages (since ROS is primarily targeted at C++ and Python).
You can also run a WebSocket server on the robot (rosbridge_suite) or an
HTTP server, so you can use any language to communicate with the
robot.

4. ROS has great simulation tools

You don't always have the ability to actually move a robot, so you need a
simulation tool. ROS has a lot of great tools like Rviz and Gazebo.
Gazebo also allows you to add physical constraints to your environment.
Therefore, when running the simulation and the real robot, the results are
almost identical. Imagine mapping a room in 3D with a drone on your
computer. This saves a lot of time. Simulation tools also allow you to

2
 view and use other robots you do not own for educational purposes or
testing in specific environments.

5. ROS can control multiple robots

ROS can work with multiple ROS masters. This means that you can have
many independent robots, each with its own her ROS system, and all
robots can communicate with each other.

ROS controlling multiple Minilab3robot

6. ROS is light
ROS core base does not occupy much space and resources. Quickly
install core packages to get you up and running in minutes. Additionally,
you can use ROS on embedded computers such as the Raspberry Pi 3
board. So, you can start new projects easily and without much effort.

7. More and more compatible ROS products

When building a robot, you don't necessarily have to reinvent or recreate
every part of it. We recommend focusing on a few development points
and integrating the rest from other manufacturers. The good news here is
that you can find many robotics products such as grippers, controller
boards, etc. that already have ROS packages. In addition to the physical
tools, the included software is also directly compatible with his ROS
system.

8. ROS is an open-source project with a permissive license

One of ROS' greatest strengths is its open source. Most core packages are
released under the BSD license. A BSD license allows you to modify and
use the code for commercial purposes without releasing the code under an
open-source license. This is useful if a company decides to integrate
open-source software.

Design Principles of ROS

ROS was designed to meet a specific set of challenges encountered when
developing large-scale service robots as part of the STAIR project at Stanford
University and the Personal Robots Program at Willow Garage, but the resulting

3
architecture is far more general than the service-robot and mobile-manipulation
domains.
The philosophical goals of ROS can be summarized as:
 Peer-to-peer
 Multi-lingual
 Tools-based
 Thin
 Free and Open-Source

1. Peer-to-peer
A system built using ROS consists of many processes on many different
hosts connected in a peer-to-peer topology at runtime. Frameworks based
on central servers (such as CARMEN [4]) can also achieve the benefits of
multi-process and multi-host designs, but central data servers are
problematic when computers are connected to heterogeneous networks.
For example, large service robots designed with ROS typically have
multiple on-board computers connected via Ethernet. This network
segment is bridged over a wireless LAN and has powerful off-board
machines performing computationally intensive tasks such as computer
vision and speech recognition.

A typical ROS network configuration

When running a central server onboard or off a robot, many message

routes are contained entirely within the subnet of the robot onboard or
off, causing unnecessary traffic to flow over the (slow) wireless link.
flow. In contrast, peer-to-peer connections avoid the problem entirely,
perhaps in combination with buffering or "fanout" software modules. A
peer-to-peer topology requires some sort of lookup mechanism for
processes to find each other at runtime.

2. Multi-lingual
When writing code, many people prefer some programming languages
over others. These preferences are the result of personal trade-offs
between programming time, ease of debugging, syntax, runtime
efficiency, and various other technical and cultural reasons. For these
reasons, we have made ROS language neutral. ROS currently supports
4
 four very different languages: C++, Python, Octave and LISP, with other
language ports in different stages of completion.
The ROS specification is at the messaging layer, nothing less. Peer-to-
peer connection negotiation and configuration is done with XML-RPC.
Good implementations of XML-RPC exist in most major languages.
Rather than providing a C-based implementation with a generated stub
interface for every major language, we prefer to implement ROS natively
in each target language to better follow each language's conventions. I
like However, in some cases it is useful to package existing 4484 libraries
to add support for new languages. The Octave client is implemented by
packaging the ROS C++ 4484 library.
The end result is a language-neutral message processing scheme where
different languages can be mixed and matched as desired.

3. Tools based
To manage the complexity of ROS, we chose a microkernel design that
uses many small tools to build and run various ROS components, rather
than a monolithic development engine, to create a runtime environment.
These tools perform various tasks such as navigating the source code tree
getting and setting configuration parameters, visualizing peer-to-peer
connection topology, measuring bandwidth utilization , graphing message
data , automatically generating documentation, and more. I could have
implemented the core services such as the global clock and logger in the
master module, but I tried to put all of the s in separate modules. We
believe that the increased stability and complexity of management more
than offset the loss of efficiency.

4. Thin
Most existing robotics software projects contain drivers or algorithms
which could be reusable outside of the project. Unfortunately, due to a
variety of reasons, much of this code has become so entangled with the
middleware that it is difficult to “extract” its functionality and re-use it
outside of its original context. To combat this tendency, we encourage all
driver and algorithm development to occur in standalone libraries that
have no dependencies on ROS. The ROS build system performs modular
builds inside the source code tree, and its use of CMake makes it
comparatively easy to follow this “thin” ideology. Placing virtually all
complexity in libraries, and only creating small executables which expose
library functionality to ROS, allows for easier code extraction and reuse
beyond its original intent. As an added benefit, unit testing is often far

5
 easier when code is factored into libraries, as standalone test programs
can be written to exercise various features of the library.
ROS re-uses code from numerous other open-source projects, such as the
drivers, navigation system, and simulators from the Player project, vision
algorithms from OpenCV, and planning algorithms from OpenRAVE,
among many others. In each case, ROS is used only to expose various
configuration options and to route data into and out of the respective
software, with as little wrapping or patching as possible. To benefit from
the continual community improvements, the ROS build system can
automatically update source code from external repositories, apply
patches, and so on.

5. Free and Open-Source

The full ROS source code is publicly available. We believe this is
important to facilitate debugging at all levels of the software stack.
Proprietary environments such as Microsoft Robotics Studio and
Webbots have many great attributes, but we believe there is no substitute
for a fully open platform. This is especially true when designing and
debugging many layers of hardware and software in parallel.
ROS is distributed under the terms of the BSD license, allowing
development for both non-commercial and commercial projects. ROS
uses interprocess communication to transfer data between modules
without the need to link modules within the same executable. Therefore,
systems built around ROS can use fine-grained licensing of various
components. Individual modules can contain software covered by a
variety of licenses, from GPL to BSD to proprietary licenses, but license
"pollution" ends with module restrictions.

Working of ROS
The fundamental concepts of the ROS implementation are nodes, messages,
topics, and services, Nodes are processes that perform computation. ROS is
designed to be modular at a fine-grained scale: a system is typically comprised
of many nodes. In this context, the term “node” is interchangeable with
“software module.” Our use of the term “node” arises from visualizations of
ROS based systems at runtime: when many nodes are running, it is convenient
to render the peer-to-peer communications as a graph, with processes as graph
nodes and the peer-to-peer links as arcs.

6
In general, ROS consists of code and tools that help you run your project's code
and do the jobs you want. This includes the infrastructure to run messages
exchanged between processes. ROS is designed as a loosely coupled system,
processes are called nodes, and each node should be responsible for a task.
Nodes communicate with each other using messages routed through logical
channels called topics.

Nodes and topics

Each node can send and receive data from other nodes using a publish/subscribe
model. We'll see it in action later. The main goal of ROS is to support code
reuse in robotics R&D so that integrated packaging systems can be found.
Again, remember that ROS is not an operating system, library, or RTOS. It is a
framework that utilizes operating system concepts.
Nodes communicate with each other by passing messages. A message is a
properly typed data structure. Standard primitive types (integer, floating point,
boolean, etc.) are supported, as are arrays of primitive types and constants.
Messages can include other messages and arrays of other messages, arbitrarily
deeply nested.

Simplest Communications Pipelines

A node sends a message by posting it to a certain topic, simply a string such as
"odometry" or "map". A node interested in a certain type of data subscribes to
the appropriate topic. There can be multiple simultaneous publishers and
subscribers for a topic, and a single node can publish and/or subscribe to
multiple topics. Generally, publishers and subscribers are not aware of the
existence of others.
Robotic perception studies are often best done with recorded sensor data, to
allow controlled comparison of different algorithms and simplify the testing
process. ROS supports this method by providing general recording and
playback functionality. Any stream of ROS messages can be transferred to disk
and replayed afterwards. It's important to note that all of this can be done from
the command line; it does not require any modification to the source code of the
graphing software.

7
For example, the following network graph can be quickly configured to collect
a data set for a visual odorometer study:

The resulting message dump can be played back into a different graph, which
contains the node under development:

As before, the initialization of nodes can be done simply by starting a process;

this can be done on the command line, in the debugger, from a script, etc.
To facilitate logging and monitoring of systems distributed across multiple
servers, the rosconsole library leverages the Apache project's log4cxx system to
provide a convenient and elegant logging interface that allows information
printf diagnostic messages are passed over the network to a single stream called
rosout.
Underlying Operating System of ROS
ROS depends on the underlying operating system. ROS requires a lot of
operating system functionality. In addition, the ROS must be freely accessible
to a large population, otherwise a large population may not be able to access it.
Much of the popularity of ROS is due to its open nature and ease of provision to
the community. It also needs an open-source operating system so that the OS
and ROS can be modified according to application requirements. Proprietary
operating systems such as Windows 10 and Mac OS X may impose certain
restrictions on their use. This can lead to rigidity during development, which
would not be ideal for an industry standard like ROS. So, most people prefer to
run ROS on Linux, especially Debian and Ubuntu, because ROS supports very
well with Debian based operating systems, especially Ubuntu. That's not to say
ROS can't run with Mac OS X or Windows 10 for that matter. However, support
is limited and people can get into serious trouble with little help from the
community.
There is a closeness between ROS and OS, to the point where it becomes almost
necessary to know more about the operating system in order to work with ROS.
Using Linux as a beginner can be challenging, One may encounter problems
with Linux especially when working with ROS, and good knowledge of Linux
will be helpful in avoiding/ solve these problems.
RViz - It is a 3D visualization tool for ROS. It is one of the most popular
visualization tools. It takes a topic as input and visualizes it based on the type of
post posted. It allows us to see the environment from the robot's perspective.
8
 RViz User Interface
Meta Operating System – It has so much functionality, that it can't be
classified as a framework or library cluster, but not so much that it can be
classified as an operating system either. It provides the functionality of both the
operating system as well as the frameworks, but is incomplete, so it cannot be
classified as such, for example, it does not provide the basic functionality that
the operating system is supposed to provide. , but provides APIs.

Installation and Configuration

ROS versions are referred to by name. As of today, the latest release is Jade
Turtle and the latest LTS release is Indigo Igloo. Better to use LTS version and
backward compatibility is not guaranteed in ROS, so all samples will be written
for Indigo. ROS is available on various *NIX platforms. The officially
supported version is on Ubuntu. The OS X, Arch Linux, Debian, Raspbian and
Android versions are supported by the community.
Installation on Ubuntu
ROS provides its own repository. The first step is to add them.

Then you will have all packages archived for all ROS versions available for
your version of Ubuntu. For example, Ubuntu 14.04 supports indigo and jade.
Installing the base package on the desktop has one of three options:
 sudo apt-get install ros-indigo-ros-base to install minimal
 sudo apt-get install ros-indigo-desktop to get basic additional graphics tools
 sudo apt-get install ros-indigo-desktop-full to have all the official functionality,
including various emulators and libraries for navigation and perception
For the best working experience, you should use the full option. For installation
on devices that will only be used to run nodes, the basic version is enough.
Whichever option you choose, you can install any necessary package named
package_name by running:
sudo apt-get install ros-indigo-<package-name>

9
The underscore is replaced by a dash in the last name, so stage_ros will be in the
ros-indigo-stage-ros.

The next step is to initialize rosdep. Packages in ROS can declare the components
they depend on. rosdep allows you to compile these packages without too much
manual dependency management. To initialize it, call:

sudo rosdep init

rosdep update

ROS has a number of environment variables used by its tools. With default
settings, the bash script to initialize them is located in /opt/ros/indigo/setup.bash.
Variables need to be initialized in each bash session, so the best solution is to
add them to ~/.bashrc.

echo "source /opt/ros/indigo/setup.bash" >> ~/.bashrc

source ~/.bashrc

Some packages install external dependencies through rosinstall, which is available

as a package and installed via sudo apt-get install python-rosinstall.

Configuration on Ubuntu
As of Groovy Galapagos, ROS workspaces are managed via catkin. We need to
define a directory for all the packages that we store. Inside the folder, we create
a src folder and call the form catkin_init_workspace inside. This will create different
symbolic for the currently derived ROS version. The next step is to add this
workspace to the environment variables.

To do this full workspace setup, select an empty directory and run the following
commands:

10
Conclusion
Robot Operating System, better known as ROS, is a completely open-source
operating system for robots. It's like a meta-OS that helps abstract the hardware
from the software. The main idea behind this is not to keep reinventing the
wheel or providing standardized functionality. This allows you to avoid wasting
time doing hardware abstractions from scratch because someone else has
already done it. Provides a brief introduction to robot programming for
hobbyists and laymen.
There are many alternatives such as MRPT, CARMEN, LCM, Player and
Microsoft RDS. Still, it fails due to design flaws such as limited language
support, unoptimized communication, or lack of hardware support for various
devices, which also poses significant problems. ROS allows software
developers to create programs without having to deal with hardware design or
how hardware works. Provides a way to connect a network of processes to a
central or master hub. Apart from that, ROS supports many programming
languages, making it much more flexible than other frameworks.

The introduction of ROS 2 expanded the range of applications that ROS can
support by adding enterprise features such as security and real-time
communication. Engineers from Amazon, LG, Bosch, Samsung, Intel and
others, led by Open Robotics, have contributed to this expanded focus. Second,
the community continues to contribute to what recently brought us ROS 2 Foxy,
the most secure and reliable ROS distribution ever. Foxy represents his 100+
engineers who have worked together to create 2 million lines of code over 6
years. This release alone is estimated to have cost him $84 million to recreate
that work. If you count the efforts of his ROS community since ROS started,
that's worth hundreds of millions of dollars.
ROS is slowly striving to become the industry standard for robotics middleware.
According to ABI Research, "nearly 55% of all commercial robots shipping in
2024, or more than 915,000 units, will have at least one of his ROS packages
installed," so there will be a sizeable installed base of ROS-enabled robots. It
will be created. “The success of ROS has been attributed to its wide
interoperability and compatibility with other open-source projects. ROS 1.0
uses Orocos for real-time communication and OpenCV for machine vision
models,” he said. said Lian Jye Su, principal analyst at ABI Research.

11
12