Introduction to Robot Operating System (ROS 1)

The ROS ecosystem consists of these four pivotal elements:

• Plumbing: ROS facilitates communication between nodes via its built-in messaging system. This messaging system streamlines the exchange of data, commands and information, promoting modularity and easier maintenance.

• Tools: ROS offers a suite of developer tools, which cover a wide range of functionalities and accelerate application development. The tools include launch, introspection, debugging, visualization, plotting, logging, and playback.

• Capabilities: The ROS ecosystem provides a variety of ready-to-use software, including drivers and algorithms. This enables you to focus on application-specific functionalities without worrying about underlying hardware capabilities.

• Community: ROS offers a thriving ecosystem supported by a global community of individuals, institutions, organizations, start-ups and corporations. The community actively contributes to ROS by sharing knowledge, creating and maintaining software packages and providing support.

This topic explains a ROS computation graph in detail.

ROS Master

ROS relies on a centralized master node called the ROS Master, to discover nodes and establish connection between them. The ROS Master provides name registration and lookup services to the rest of the nodes in the network, enabling them to discover and communicate with each other. It enables the nodes to find each other and exchange messages between themselves. The ROS_MASTER_URI is the environment variable that specifies the address of the ROS Master. This URI allows nodes to find and communicate with the ROS Master.

Nodes

Nodes are the basic building blocks of ROS applications, that are responsible for all the computations. They are independent processes that communicate with each other by sending and receiving messages. Nodes register themselves with the ROS Master upon startup, providing their name and the topics they publish or subscribe to, services they offer, and parameters they use. A robot control system typically comprises multiple nodes, each responsible for a specific task, such as sensor data processing, motor control, or decision-making. Nodes in ROS are designed to be modular and can be developed and run independently, allowing for a flexible and scalable system architecture.

Discovery

Node discovery in ROS is managed by the ROS Master. When a node starts, it registers with the ROS Master, providing information about the topics it publishes or subscribes to. When another node wants to communicate, it queries the ROS Master to get the necessary information to establish a direct peer-to-peer connection with the other node.

Nodes communicate with other nodes using one of the three communication interfaces: topics, services and actions.

Topics

The individual communication channels that nodes use to communicate with other nodes are called topics. A topic is used for unidirectional, many-to-many communication. Each topic has a defined message type that specifies the structure of the data being transmitted. It can have several nodes publishing to it, and several nodes subscribing to it. The ROS Master facilitates the initial connection between publishers and subscribers.

• Publisher –– Publishers are nodes that produces data. A node can publish a specific type of message over a topic and make it available for other nodes.

• Subscriber –– Subscribers are nodes that consumes data. A node can subscribe to messages or information published on a topic.

Topics are used to publish and subscribe to data that is continuously updated, including sensor data and robot state.

Messages

Messages are the data units exchanged between nodes. They are described in a .msg file and have two parts, namely fields and constants. Messages comprise fields of various types, such as integers, floating-point numbers, strings, or arrays. When a node publishes a message to a topic, it sends an instance of the message type associated with that topic. Subscriber nodes receive and process these message instances. Messages can contain any type of data, such as sensor readings, actuator commands, images, and so on.

Services

Nodes also communicate with each other using services, similar to topics, but they use synchronous, request-reply interactions exclusive to services. Unlike topics, which handle continuous data streams, services are designed for discrete interactions. Services are commonly employed for tasks that necessitate confirmation or prompt action, such as directing a robot to move to a designated position. A service message is described in a .srv file and comprises of two parts, a request and a response.

• Client –– A service client is the node which requests to perform a computation on its behalf. The client creates the request part of the service message.

• Server –– A service server is the node which accepts the service request and performs the required computation. The server then fills up the response part of the service message.

Services are used for remote procedure calls that are typically short-lived, such as querying the state of a node, performing calculations or conversions, etc.

Actions

Action is another communication mechanism for long-running tasks. A node, known as the action client, sends a goal to another node, known as the action server, which provides periodic feedback on the goal's progress and sends a result message upon completion. Clients also have the ability to cancel goals if required. An action message is defined in a .action file and comprises of three parts: a goal, feedback and a response.

• Client –– An action client is the node which requests a goal to be completed. It tracks the execution status of the goal and cancel them if necessary.

• Server –– An action server is the node which accepts the goal and handles the execution of actions requested by the action client. It sends out feedback as the action progresses and returns a result when the goal is achieved.

Actions are used for tasks that involve multiple steps with feedback, such as navigation (reaching a specific location) and manipulation (picking up an object).

Packages

Packages are the primary organizational unit of software in ROS. A package contains the source code, build scripts, and metadata for a piece of software. Packages can include nodes, message definitions, services, actions, libraries, and configuration files. They are designed to be reusable and shareable, making it easy to distribute and collaborate on ROS-based software. Packages are managed using tools like catkin and rosbuild.

A workspace is a directory containing ROS packages. Workspaces provide a structured hierarchy, ensuring that packages are organized effectively. A single workspace can contain several packages, each in their own folder.

Parameters

Parameters are configuration settings stored on a central parameter server, part of the ROS Master. These parameters can be accessed and modified by nodes at runtime. In MATLAB^®, you can interact with the parameter server to set a parameter, retrieve a parameter, and delete a parameter. This allows for dynamic and centralized management of configuration settings, making it easier for multiple nodes to share and update crucial data during operation. Each parameter is made of two parts: a key and a value. The key, which is a string, names the parameter, while the value can be of various types, such as integers, floats, booleans, strings, or lists (arrays).

ROS Integration in MATLAB and Simulink

This image provides a high-level overview of how ROS is implemented and integrated within MATLAB^® and Simulink^® environments. It breaks down the integration into three layers: application layer, middleware layer, and communication layer.

• Application layer –– MATLAB and Simulink offer APIs and blocksets for integration with ROS, enabling users to incorporate their custom code and models into MATLAB scripts and Simulink models. This facilitates the utilization and ROS 2 capabilities within these environments.

• Middleware layer –– The middleware layer in ROS is managed by the ROS Master, which handles node registration, parameter server, and topic/service communication. It bridges the application layer (MATLAB and Simulink^®) with the communication layer. It includes client libraries and APIs that facilitate communication and interaction with ROS system.

• Communication layer –– The underlying communication protocol for ROS is TCP/UDP, which handles the actual data exchange between nodes in a distributed system.

Related Topics

• Connect to ROS Network and Establish Communication

External Websites

• Robot Operating System(ROS)