1. Objective — What You Are Learning and Why

In this lesson you will understand how ROS architecture is organized.

This is one of the most important ideas in robotics, because if you understand the architecture, you stop seeing a robot as:

one big block of code

and you start seeing it as:

many small pieces working together

That is exactly how real robotic systems are built.

The key message of this lesson is this:

ROS is robot-agnostic.

This means ROS is not built for only one robot.

It is not only for a KUKA robot.
It is not only for a Raspberry Pi robot.
It is not only for a 6-axis arm.

ROS gives you a general structure that can work with many different robots.

You can use the same logic for:

• a mobile robot
• a robotic arm
• a drone
• a camera system
• an industrial pick-and-place cell

That is powerful, because once you understand the structure, you can reuse the same way of thinking in many applications.

In this lesson, I will use a very simple example:

a pick-and-place application using a camera

Imagine a robot that must see an object, understand where it is, compute how to reach it, and then move to pick it.

This may sound like one task, but in ROS we split it into smaller parts.

That is the big idea of the lesson.

From the Real World to the Application

A robot lives in the real world.

In the real world, you have:

• sensors
• actuators
• motors
• cameras
• grippers

These are physical things.

But your code cannot talk directly to metal, wires, and motors in a magical way.

So between the real world and your application, we need layers.

You can think of it like this:

1. Real world

This is where the robot really exists.

For example:

• camera
• motor
• encoder
• gripper

2. Drivers

Drivers are the first software layer that talks to the hardware.

A driver is like a translator between software and a physical device.

For example:

• a camera driver reads images from the real camera
• a motor driver sends commands to the motor
• a robot driver sends commands to the robot controller

Without drivers, ROS cannot access the real hardware.

3. Controllers

Controllers sit above the drivers.

They organize how the hardware should behave.

For example:

• move this joint to this position
• keep this speed
• read this state continuously

You can think of a controller as the layer that gives structure to how hardware is managed.

4. ROS framework, libraries, and application

Above that, you have the ROS world.

This is where your robotic application lives.

Here you build things such as:

• camera processing
• object detection
• motion planning
• decision making
• task logic

This is where ROS becomes powerful.

Because now you are no longer programming one motor at a time.

You are building a complete robot behavior.

Example: Pick and Place with a Camera

Let’s take a simple example.

You have:

• a camera
• a robot arm
• an object on a table

Your goal is to pick the object.

If you write everything inside one giant program, it becomes messy very quickly.

So in ROS, you split the system into nodes.

A node is just a small program that does one job.

For example, your pick-and-place application could be split like this:

Camera node

This node reads the camera data in real time.

Its job is simply:

get images from the real camera

Vision processing node

This node takes the camera data and processes it.

Its job could be:

• detect the object
• estimate the position
• extract useful information

Inverse kinematics or planning node

This node takes the target position and computes how the robot should move.

Its job is:

turn “the object is here” into “the robot joints should move like this”

Execution node

This node sends the command to the robot and executes the motion.

Its job is:

actually move the robot

So now you no longer have one giant program.

You have several nodes, and each node does one thing well.

That is why ROS scales so well.

Nodes Need to Communicate

Now comes the next important idea.

If the system is split into nodes, then the nodes must talk to each other.

ROS gives you three main ways to do that:

• Topics
• Services
• Actions

These are the three main Topics

A topic is a stream of data.

The easiest way to think about a topic is like a radio channel.

A node publishes data on that channel.

Another node can listen to that channel.

For example:

• topic name: /camera/image_raw
• message type: sensor_msgs/msg/Image

This means:

• the topic has a name
• the data has a type

The topic name tells you where to listen.
The message type tells you what kind of data is traveling.

For example, /camera/image_raw could continuously publish images from the camera.

A camera node publishes.
A vision node subscribes.

That is a topic-based communication.communication tools you will use all the time.

Publish and Subscribe

A node can:

• publish to a topic
• subscribe to a topic

This is very important.

And here is one of the most beautiful ideas in ROS:

nodes are blind to who exactly is publishing

The subscriber does not care who is sending the message.

It only cares that someone is publishing data on that topic with the correct message type.

That is why I like the radio example.

If you tune your radio to one frequency, you hear the music.

You do not need to know who is physically standing in the radio station.

Same thing in ROS.

A node just listens on the topic.

This makes the architecture very flexible.

You can replace one node with another node, and if it publishes the same topic with the same type, the rest of the system keeps working.

That is another example of ROS being robot-agnostic and modular.

Service

Now let’s move to services.

A service is different from a topic.

A topic is a continuous stream.

A service is more like:

I ask for something, and I wait for the answer

So a service has:

• a request
• a response

A very simple analogy is a website.

Your browser sends a request:

give me this webpage

The server sends a response:

here is the webpage

That is basically the idea.

In ROS, one node is the service client, and another node is the service server.

For example, you could ask:

compute inverse kinematics for this target pose

The client sends the request.
The server computes the answer.
Then it sends back the response.

This is useful when you want one specific answer to one specific question.

Important note about services

A service is usually synchronous.

That means:

• I send the request
• I wait
• then I get the response

This is fine for short tasks.

But it becomes a problem if the operation takes time.

Because while waiting, part of the system can remain blocked.

And that brings us to actions.

Actions

An action is used when something takes longer time.

An action is asynchronous.

This means:

• you send a goal
• the system starts working
• but the rest of the system does not need to freeze

This is extremely useful in robotics.

Let’s take a simple example.

Imagine a 6-axis robot arm has to move its end effector to a certain position.

That motion may take:

• one second
• two seconds
• maybe more

This is not instant.

And during that time, you may want to do other things.

For example:

• check progress
• stop the motion
• cancel the goal
• monitor feedback
• wait for the final result

If you used a service for this, it would be too rigid.

That is why actions exist.

What happens in an action

An action usually has these parts:

• goal
• feedback
• result
• optionally cancel

Let’s keep it very simple.

Goal

This is what you want to do.

Example:

move the robot to this position

Feedback

This is information you receive while the action is still running.

Example:

• current progress
• current state
• how far the robot is from the target

So while the robot is moving, you can still know what is happening.

Result

This is the final answer at the end.

Example:

• success
• failed
• target reached

This tells you how the action ended.

Cancel

Sometimes you change your mind.

Maybe the robot is moving, but suddenly:

• the object moved
• a person entered the workspace
• you sent the wrong target

In this case, you may want to cancel the current action.

That is why actions support canceling.

A Simple Real Example

Imagine this situation.

You tell the robot:

go pick that object

This is the goal.

While the robot is moving, you can receive feedback like:

I am 40% done
I am close to the target
I am still moving

If something changes, you can send cancel:

stop that action

And at the end, you receive the result:

target reached successfully

This is why actions are perfect for motion execution.

They are built for tasks that take time.

Why Topics, Services, and Actions All Matter

At the beginning, these three communication tools can feel confusing.

But the rule is actually simple:

Use a topic when:

you want to stream data continuously

Example:

• camera images
• joint states
• laser scans

Use a service when:

you want to ask something and get one answer back

Example:

• compute something
• trigger something quick
• ask for a configuration value

Use an action when:

the task takes time and you need progress, canceling, or final result

Example:

• move the robot
• follow a trajectory
• navigate to a point

Why This Architecture Is Powerful

Now you can see why ROS is so useful.

Instead of hardcoding everything into one program, ROS lets you build a robot like a team of small workers.

One worker sees.
One worker thinks.
One worker plans.
One worker moves.

And they communicate through standard tools:

• topics
• services
• actions

This makes the system:

• modular
• scalable
• reusable
• robot-agnostic

That last point is very important.

The same architecture can work whether you use:

• a small robot on a Raspberry Pi
• a mobile robot
• a 6-axis industrial arm
• a simulation system

The hardware changes.
The architecture idea stays the same.

That is one of the biggest strengths of ROS.

2. Key Takeaways

After this lesson, you should remember these simple ideas.

ROS architecture is built in layers.

At the bottom you have the real world:

• sensors
• actuators
• motors
• cameras

Above that you have:

• drivers
• controllers

And above that you build the ROS application.

A robotic application is split into nodes.

Each node does one job.

Those nodes communicate through:

• topics for continuous data streams
• services for request and response
• actions for long tasks with feedback and result

You should also remember this key message:

ROS is robot-agnostic.

It gives you a general way to structure robotic systems, no matter which robot you use.

And that is exactly why learning ROS is so valuable.