Solution: ROS Architecture and Its Use

Introduction

ROS (Robot Operating System) is a middleware and software framework used to develop robotic applications. It provides communication, tools, libraries, visualization and hardware integration rather than being a conventional operating system.

ROS Architecture

             ROS Master / Discovery
                     │
       ┌─────────────┼─────────────┐
       ↓             ↓             ↓
    Node A         Node B        Node C
   (Camera)       (Control)     (Lidar)
       │             │             │
       └──── Topics / Services / Actions ────┘
                     │
                Robot Hardware

1. Nodes

A node is an executable process responsible for a particular function, such as sensor acquisition, localization or motor control.

2. Topics

Topics provide asynchronous publish/subscribe communication. A camera node can publish images while another node subscribes to them.

3. Services

Services provide request-response communication for operations that need a defined reply.

4. Actions

Actions are suitable for long-running tasks and provide feedback, status and the ability to cancel a goal.

5. Messages

Nodes exchange structured data using predefined or custom message types.

6. Packages and Catkin Workspace

ROS software is organized into packages. A Catkin workspace contains source packages and build/devel/install outputs in ROS 1 workflows.

Use in Modern Robotics

ROS is used for:

• Robot control
• Sensor integration
• Autonomous navigation
• SLAM and mapping
• Computer vision
• Manipulation
• Simulation
• Human-robot interaction
• Multi-robot systems

Advantages

1. Modular architecture
2. Reusable software packages
3. Hardware abstraction
4. Standard communication mechanisms
5. Strong simulation and visualization ecosystem
6. Easy integration of sensors and algorithms

Conclusion

ROS enables complex robot systems to be divided into independent software components that communicate through standardized interfaces, making development, testing and maintenance easier.

Solution: Setting Up a Catkin Workspace

A Catkin workspace is a directory structure used to organize and build ROS 1 packages.

Steps

1. Create the workspace

mkdir -p ~/catkin_ws/src
cd ~/catkin_ws/src

The src directory contains ROS packages.

2. Initialize the workspace

From the workspace root:

cd ~/catkin_ws
catkin_make

This creates build and devel directories and generates the required build configuration.

3. Source the workspace

source ~/catkin_ws/devel/setup.bash

This makes packages in the workspace available in the current terminal.

To source it automatically:

echo "source ~/catkin_ws/devel/setup.bash" >> ~/.bashrc
source ~/.bashrc

4. Create a package

cd ~/catkin_ws/src
catkin_create_pkg my_robot_pkg roscpp rospy std_msgs

The package now contains its manifest and build configuration.

5. Build the workspace

cd ~/catkin_ws
catkin_make

6. Verify the package

rospack find my_robot_pkg

If the package path is returned, the workspace is correctly sourced.

Workspace Structure

catkin_ws/
├── src/
│   └── my_robot_pkg/
│       ├── src/
│       ├── include/
│       ├── CMakeLists.txt
│       └── package.xml
├── build/
└── devel/

Conclusion

The normal workflow is create workspace → initialize/build → source → create packages → build again → verify. This provides an organized environment for ROS development.

Solution: ROS Services vs ROS Actions

Both ROS Services and Actions provide communication between ROS nodes, but they are designed for different kinds of tasks.

Feature	ROS Service	ROS Action
Communication	Request-response	Goal-feedback-result
Task type	Short operations	Long-running operations
Feedback	Normally no continuous feedback	Provides continuous feedback
Cancellation	Not designed for cancellation	Goal can be cancelled/preempted
Result	Returned after request	Final result returned separately
Example	Reset a sensor	Navigate to a destination

ROS Service

A service is synchronous request-response communication.

Client → Request → Service Server
Client ← Response ← Service Server

Examples include resetting a controller, requesting a calculation or changing a configuration parameter.

ROS Action

An action is intended for operations that may take significant time.

Client → Goal → Action Server
Client ← Feedback ← Action Server
Client ← Result ← Action Server
        ↑
      Cancel

For example, autonomous navigation may take several seconds or minutes. The client can receive distance/progress feedback and cancel the goal if necessary.

Conclusion

Use a Service for short request-response operations and an Action for long-running, feedback-producing and cancellable tasks.