Review of Robot Operating System

Abstract— This paper gives an overview of ROS, an (RDEs) have been developed that support various aspects of
opensource robot operating system. ROS is not an operating the agent development process, ranging from the design of
system in the traditional sense of process management and an agent architecture, to its implementation on robot
scheduling; rather, it provides a structured communications hardware, to executing it on the robot.
layer above the host operating systems of a heterogenous
compute cluster. In this paper, we discuss how ROS relates to A robot operating system (ROS) is similar to that of an
existing robot software frameworks, and briefly overview some operating system on a personal computer, in that it comprises
of the available application software which uses ROS. a collection of programs which offer control to a user. In the
Introduction. case of an ROS however, these programs allow a user to
control the mobile operations of a robot rather than
Recently the scope and scale of robotics has grown applications on a computer. A good ROS will also make this
tremendously and is expected to continue to grow in coming control user-friendly.[3]
years. But as the field of robotics is continuing to grow, we
are also facing a lot of challenges to make our various plant A. About ROS
systems to work efficiently.[1] The real model ROS, the framework described in this paper, is the
implementation is still a tough task to work on. A lot of product of tradeoffs and prioritizations made during its
experimentation and training of a physical model has to be design cycle. We believe its emphasis on large-scale
done so that when brought to real life, it can perform as per integrative robotics research will be useful in a wide variety
the expectations. But doing practical experiments on the real of situations as robotic systems grow ever more complex.
model has several disadvantages to it. Wear & tear, fatigue ROS is an open-source, meta-operating system for wer
and permanent damage are some problems that are faced by robot. It provides the services we would expect from an
practical implementation. So, instead of implementing on operating system, including hardware abstraction, low-level
real model, it is better to simulate a real-life environment device control, implementation of commonly-used
where we can give a particular command to our virtual robot. functionality, message-passing between processes, and
package management. It also provides tools and libraries for
To meet these challenges, many robotics researchers have obtaining, building, writing, and running code across
previously created a wide variety of frameworks to manage multiple computers.[4]
complexity and facilitate rapid prototyping of software for
experiments, resulting in the many robotic software systems B. Why ROS?
currently used in academia and industry.[2] Each of these After knowing things about ROS, we also need to
frameworks was designed for a particular purpose, perhaps consider what created its need. We will also look at the
in response to perceived weaknesses of other available advantage of using this kind of platform.
frameworks, or to place emphasis on aspects which were
Distributed computation: Many modern robot systems rely
seen as most important in the design process.
on software that spans many different processes and runs
across several different computers. For example: Some
robots carry multiple computers, each of which controls a
subset of the robot’s sensors or actuators. Even within a
single computer, it’s often a good idea to divide the robot’s
software into small, stand-alone parts that cooperate to
achieve the overall goal. This approach is sometimes called
“complexity via composition.” When multiple robots
attempt to cooperate on a shared task, they often need to
communicate with one another to coordinate their efforts.
Human users often send commands to a robot from a laptop,
a desktop computer, or mobile device. We can think of this
human interface as an extension of the robot’s software. The
Robots, unlike many software agents, operate under common thread through all of these cases is a need for
realworld, real-time constraints where sensors and effectors communication between multiple processes that may or may
with specific physical characteristics need to be controlled. not live on the same computer. ROS provides two relatively
To facilitate research in autonomous robotics and help simple, seamless mechanisms for this kind of
architecture designers in managing the complexity of
communication.
embodied agents, several robot development environments
Software reuse: The rapid progress of robotics research has ROS does include client libraries, it also includes (among
resulted in a growing collection of good algorithms for other things), a central server, a set of command-line tools, a
common tasks such as navigation, motion planning, set of graphical tools, and a build system. ROS is not an
mapping, and many others. Of course, the existence of these integrated development environment. Although ROS does
algorithms is only truly useful if there is a way to apply not prescribe any particular development environment, it
them in new contexts, without the need to reimplement each can be used with most popular IDEs.Í8 It is also quite
algorithm for each new system. ROS can help to prevent reasonable (and, indeed, it is the author’s personal
this kind of pain in at least two important ways. ROS’s preference) to use ROS from a text editor and the command
standard packages provide stable, debugged line, without any IDE.
implementations of many important robotics algorithms.
ROS’s message passing interface is becoming a de facto
standard for robot software interoperability, which means II. GENERAL TERMS AND CONCEPTS
that ROS interfaces to both the latest hardware and to
implementations of cutting edge algorithms are quite often ROS’ philosophy can be summarised in the following five
available. For example, the ROS website lists hundreds of main principles:
publicly-available ROS packages.Í2 This sort of uniform
interface greatly reduces the need to write “glue” code to  Peer-to-Peer
connect existing parts. As a result, developers that use ROS  Tools-based (microkernel)
can expect—after, of course, climbing ROS’s initial  Multi-language
learning curve—to focus more time on experimenting with  Thin
new ideas, and less time reinventing wheels.  Free and open source.
Rapid testing: One of the reasons that software development
for robots is often more challenging than other kinds of Covering each point in turn:
development is that testing can be time consuming and
error-prone. Physical robots may not always be available to Peer to Peer: A sufficiently complex robot comprises
work with, and when they are, the process is sometimes several on board computers or boards connected via
slow and finicky. Working with ROS provides two effective Ethernet, plus sometimes off board computers for intensive
workarounds to this problem. Well-designed ROS systems computation tasks. A peer-to-peer architecture coupled to a
separate the low-level direct control of the hardware and buffering system and a lookup system (a name service
high-level processing and decision making into separate called ‘master’ in ROS), enables each component to
programs. Because of this separation, we can temporarily dialogue directly with any other, synchronously or
replace those low-level programs (and their corresponding asynchronously as required.
hardware) with a simulator, to test the behavior of the high-
level part of the system. ROS also provides a simple way to Multi-language: ROS is language-neutral, and can be
record and play back sensor data and other kinds of programmed in various languages. The ROS specification
messages. This facility means that we can obtain more works at the messaging layer. Peer-to-peer connections are
leverage from the time we do spend operating a physical negotiated in XML-RPC, which exists in a great number of
robot. By recording the robot’s sensor data, we can replay it languages. To support a new language, either C++ classes
many times to test different ways of processing that same are re-wrapped (which was done for the Octave client, for
data. In ROS parlance, these recordings are called “bags” example) or classes are written enabling messages to be
and a tool called rosbag is used to record and replay them. A generated. These messages are described in IDL (Interface
crucial point for both of these features is that the change is Definition Language).
seamless. Because the real robot, the simulator, and the bag
playback mechanism can all provide identical (or at least Tools-based: Rather than a monolithic runtime environment,
very similar) interfaces, wer software does not need to be ROS adopted a microkernel design, which uses a large
modified to operate in these distinct scenarios, and indeed number of small tools to build and run the various ROS
need not even “know” whether it is talking to a real robot or components. As we cover the ROS tutorials, we will learn to
to something else. Of course, ROS is not the only platform use several commands used to manipulate nodes and
that offers these capabilities. What is unique about ROS, at messages. Each command is in fact an executable. The
least in the author’s judgment, is the level of widespread advantage of this system is that a problem with one
support for ROS across the robotics community. This executable does not affect the others, which makes the
“critical mass” of support makes it reasonable to predict that system more robust and flexible than a system based on a
ROS will continue to evolve, expand, and improve in the centralised runtime environment.
future.
Thin: To combat the development of algorithms that are
C. Misconceptions about ROS entangled to a lesser or greater degree with the robotics OS
ROS is not a programming language. In fact, ROS and are therefore hard to reuse subsequently, ROS
programs are routinely written in C++. Client libraries are developers intend for drivers and other algorithms to be
also available for Python,Í4 Java,Í5 Lisp,Í6 and a handful of contained in standalone executables. This ensures maximum
other languages.Í7 ROS is not (only) a library. Although reusability and, above all, keeps its size down. This method
makes ROS easy to use, the complexity being in the
libraries. This arrangement also facilitates unit testing.
Lastly, ROS uses code (drivers and algorithms) from other
open source projects:

 Player/Stage project simulators

 Image processing and artificial vision libraries
from OpenCV
 Planning algorithms from OpenRave
 etc

Free and open source: We have already explained the

reasons for this choice. Note however that the architecture
chosen is consistent with that choice. ROS passes data
between modules using inter-process communications and,
as a result, modules do not need to be linked within a single
process, thereby making the use of different licences a In registering with the ROS Master, the Camera Node states
possibility. that it will Publish a Topic called /image_data (for
example). Both of the other Nodes register that they are
Subscribed to the Topic /image_data.
Let’s look at the ROS system from a very high level
view. No need to worry how any of the following works, we
will cover that later. ROS starts with the ROS Master. The Thus, once the Camera Node receives some data from the
Master allows all other ROS pieces of software (Nodes) to Camera, it sends the /image_data message directly to the
find and talk to each other. That way, we do not have to ever other two nodes. (Through what is essentially TCP/IP)
specifically state “Send this sensor data to that computer at
127.0.0.1. We can simply tell Node 1 to send messages to
Node2.

How do Nodes do this?

By publishing and subscribing to Topics. A Node can register a specific service with the ROS Master,
Let’s say we have a camera on our Robot. We want to be just as it registers its messages. In the below example, the
able to see the images from the camera, both on the Robot Image Processing Node first requests /image_data, the
itself, and on another laptop. Camera Node gathers data from the Camera, and then sends
In our example, we have a Camera Node that takes care of the reply.
communication with the camera, a Image Processing Node
on the robot that process image data, and a Image Display
Node that displays images on a screen. To start with, all
Nodes have registered with the Master. Think of the Master
as a lookup table where all the nodes go to find where
exactly to send messages.
 III. EXPERIMENTAL & SIMULATION WORK The topics and executable in the turtlesim are described
below. The rosrun command takes the arguments [package
name] [node name]. The node creates the screen image and
We performed a simulation on a virtual robot the turtle. Here the turtle is in the center in x=5.5, y=5.5
TURTLESIM which comes as a package in ROS. with no rotation.
ROS Nodes with Turtlesim
$ rosnode list
/rosout
/turtlesim
Note the difference in notation between the node /turtlesim
and the package turtlesim.
Node [/turtlesim]
Publications: (This information is sent to nodes listening
to /turtlesim)
* /turtle1/color_sensor [turtlesim/Color] (Color message in
turtlesim package)
* /rosout [rosgraph_msgs/Log]
* /turtle1/pose [turtlesim/Pose] (Pose message in turtlesim
package for /turtle1)
Subscriptions: * /turtle1/cmd_vel [unknown type] (This
node will listen for command velocities)
TURTLESIM NODE TOPIC POSE
The above simulation is performed in Linux based Another topic for turtlesim node is the turtle’s pose. This is
system. We tried to give certain trajectory through ROS the x, y position, angular direction, and the linear and
commands and then communicated to it by creating node. angular velocity.
After we have started turtlesim by executing the rosrun $ rostopic info /turtle1/pose
command, we will see information about the turtle's position Type: turtlesim/Pose Publishers: * /turtlesim
on the screen. The /turtlesim node creates the screen image Subscribers: None
and the turtle. Here, the turtle is in the center at about x = :~$ rostopic type /turtle1/pose
5.5, y = 5.5 with no rotation since angle theta is zero. The turtlesim/Pose
origin (0, 0) is at the lower-left corner of the screen. ~$ rosmsg show turtlesim/Pose
float32 x
The following diagram represents a graphical illustration float32 y
of the relationship of the turtlesim node in elliptical shapes float32 theta
and topics in rectangular boxes
float32 linear_velocity
float32 angular_velocity

example:
rostopic echo /turtle1/pose
x: 2.0
y: 1.0
theta: 0.0
linear_velocity: 0.0
angular_velocity: 0.0
---
x: 2.0 ENABLE KEYBOARD CONTROL OF TURTLE
y: 1.0 In a third window, we execute a node that allows keyboard
theta: 0.0 control of the turtle. Roscore is running in one window and
linear_velocity: 0.0 turtlesim_node in another.
angular_velocity: 0.0 $ rosrun turtlesim turtle_teleop_key
Reading from keyboard ---------------------------
Type of message for cmd_vel Use arrow keys to move the turtle.
Up arrow Turtle In Turtle’s x direction
rostopic type /turtle1/cmd_vel Down arrow Turtle In Turtles’s -x direction
geometry_msgs/Twist Right arrow Rotate CW
rosmsg show geometry_msgs/Twist Left arrow Rotate CCW
geometry_msgs/Vector3 linear
float64 x Node [/teleop_turtle]
float64 y Publications:
float64 z * /turtle1/cmd_vel [geometry_msgs/Twist]
geometry_msgs/Vector3 angular * /rosout [rosgraph_msgs/Log]
float64 x
float64 y Subscriptions: None
float64 z

$ rostopic type /turtle1/cmd_vel | rosmsg show

geometry_msgs/Vector3 linear
float64 x
float64 y
float64 z
geometry_msgs/Vector3 angular
float64 x
float64 y
float64 z

The requirement is for two vectors with 3 elements each.

The message type is geometry_msgs/Twist .
This displays a verbose list of topics to publish to and
subscribe to and their type:
$ rostopic list -v
Published topics:
* /turtle1/color_sensor [turtlesim/Color] 1 publisher
* /rosout [rosgraph_msgs/Log] 1 publisher
* /rosout_agg [rosgraph_msgs/Log] 1 publisher
* /turtle1/pose [turtlesim/Pose] 1 publisher Determine data from Topic /turtle1/cmd_vel
Subscribed topics: The rostopic echo command shows the data sent by the
* /turtle1/cmd_vel [geometry_msgs/Twist] 1 subscriber node to control the turtle. As you move the turtle, the data
* /rosout [rosgraph_msgs/Log] 1 subscriber are updated. As you press the arrow keys the displayed
values will change: x velocity if linear motion, z velocity if
MOVE TURTLE ONCE rotation.
The following command will send a single message to $ rostopic echo /turtle1/cmd_vel
turtlesim telling it to move with a linear velocity of 2.0, and linear:
an angular velocity of 1.8. It will move from its starting x: 2.0 (Velocity ahead)
position along a circular trajectory for a distance and then y: 0.0
stop. z: 0.0
$ rostopic pub -1 /turtle1/cmd_vel geometry_msgs/Twist angular:
-- '[2.0, 0.0, 0.0]' '[0.0, 0.0, 1.8]' x: 0.0
-r RATE, --rate=RATE publishing rate (hz). y: 0.0
For -f and stdin input, this defaults to 10. z: 0.0
Otherwise it is not set. -1, ---
--once publish one message and exit linear:
x: 2.0
rqt_plot We can plot information about the nodes and y: 0.0
topics. z: 0.0
angular:
x: 0.0
y: 0.0 FUTURE SCOPE
z: 0.0
--- We have to learn about building an actual robot with real
. life environment. This platform also allows the addition of
. sensors, different road conditions that can be done using
These show the parameters for cmd_vel which are linear GAZEBO.
velocity and angular velocity. In this result, the turtle was
moved linearly until the last output which shows a rotation.

To find turtle’s position in window use /turtle1/pose

:~$ rostopic echo /turtle1/pose
x: 5.544444561
y: 5.544444561
theta: 0.0
linear_velocity: 0.0
angular_velocity: 0.0
.
.
CNTL+c to stop output.
Here the turtle is at rest in the center of the window. If we
return to the teleop_key window and move the turtle with
the arrow keys we can see the output of the pose message
(turtlesim/Pose) change.
Remember the format:
rosmsg show turtlesim/Pose
float32 x
float32 y
float32 theta
float32 linear_velocity
float32 angular_velocity
We can make the turtle turn in a circle by publishing the
topic /turtle1/command_velocity as shown before using the
node /turtlesim.
$rostopic geometry_msgs/Twist -- '[2.0, 0.0, 0.0]' '[0.0,
0.0, 1.8]'pub -r 1 /turtle1/cmd_vel

CONCLUSION

We can say that ROS is a great open-source middleware to

use for our robot. Depending on our previous knowledge,
the learning curve can be slow at the beginning. But in a few
weeks we will be able to understand more and more stuff,
and our productivity will be much higher. Plus, our robot
will do amazing things that we can’t just program on your
own.

We can choose between C++ and Python for programming

with ROS. If we want fast prototyping and are not so
familiar with C++ then PYTHON is recommended. One of
the goals of ROS is to ease the sharing and reuse of code
from other people, so we need to find out what exists that
we don’t need to code yourself, what modules best match
our needs, what kind of service or messages you need to
use… This in way longer an requires some time reading the
docs, forums and testing.