
Robot Operating System (ROS or ros) is an open source robotics middleware suite. Although ROS is not an operating system
but a collection of software frameworks for robot software development, it provides services designed for a heterogeneous
computer cluster such as hardware abstraction, low-level device control, implementation of commonly used functionality,
message-passing between processes, and package management. Running sets of ROS-based processes are represented in a
graph architecture where processing takes place in nodes that may receive, post and multiplex sensor data, control, state,
planning, actuator, and other messages. Despite the importance of reactivity and low latency in robot control, ROS itself is
not a real-time OS (RTOS). It is possible, however, to integrate ROS with real-time code. The lack of support for real-time
systems has been addressed in the creation of ROS 2.0,a major revision of the ROS API which will take advantage of modern
libraries and technologies for core ROS functionality and add support for real-time code and embedded hardware.
ROS has three levels of concepts: the Filesystem level, the Computation Graph level, and the Community level. These levels
and concepts are summarized below and later sections go into each of these in greater detail.
A node represents a single process running the ROS graph. Every node has a name, which it registers with the ROS master
before it can take any other actions. Multiple nodes with different names can exist under different namespaces, or a node can
be defined as anonymous, in which case it will randomly generate an additional identifier to add to its given name. Nodes
are at the center of ROS programming, as most ROS client code is in the form of a ROS node which takes actions based on
information received from other nodes, sends information to other nodes, or sends and receives requests for actions to and
from other nodes.
ROS processes are represented as nodes in a graph structure, connected by edges called topics. ROS nodes can pass
messages to one another through topics, make service calls to other nodes, provide a service for other nodes, or set or
retrieve shared data from a communal database called the parameter server. A process called the ROS Master[66] makes all
of this possible by registering nodes to itself, setting up node-to-node communication for topics, and controlling parameter
server updates. Messages and service calls do not pass through the master, rather the master sets up peer-to-peer communi-
cation between all node processes after they register themselves with the master. This decentralized architecture lends itself
well to robots, which often consist of a subset of networked computer hardware, and may communicate with off-board
computers for heavy computation or commands.
Topics are named buses over which nodes send and receive messages. Topic names must be unique within their namespace
as well. To send messages to a topic, a node must publish to said topic, while to receive messages it must subscribe. The
publish/subscribe model is anonymous: no node knows which nodes are sending or receiving on a topic, only that it is
sending/receiving on that topic. The types of messages passed on a topic vary widely and can be user-defined. The content
of these messages can be sensor data, motor control commands, state information, actuator commands, or anything else.
3 Development Guide
3.1 ROS Development Introduction
3.1.1 ROS History
3.1.2 ROS Concept
3.1.3 ROS Node
3.1.4 ROS Message
3.1.4.1 ROS Topic
11
____
_
_