DEV Community: Eric Young

Create A ROS2 Node: Series Overview

Eric Young — Mon, 19 Jan 2026 15:35:08 +0000

Build ROS2 nodes faster, smarter, and more efficiently

This series of articles is designed with YOU in mind. It follows a logical, step-by-step progression - from the basics of node creation to using templates and plug-and-play elements to accelerate your development.

After starting with a simple node, we quickly transition to object-oriented programming (OOP) to create reusable templates and extensions that let you build nodes quickly and efficiently.

By the end, you'll be able to spin up fully functional ROS2 nodes with minimal boilerplate.
Get your robotics projects up to speed with the following CREATE A NODE: articles in the series:

The Argument For Non-OOP vs. OOP
TEMPLATE - Basic OOP Node
PUB/SUB Publisher
PUB/SUB Subscriber
PUB/SUB Comparison
SERVICES - server
SERVICES - client
SERVICES - A Comparison

Articles will be available in both Python and C++.

If this helped:
❤️ React • 💬 Comment • 🔖 Save • 🚀 Boost • 🔗 Share
Follow for ROS2, robotics, and systems tutorials.

ROS2 SYSTEMS ANALYSIS: Visualizing Workspaces, Nodes & Communication

Eric Young — Mon, 19 Jan 2026 15:29:16 +0000

**## A beginner-friendly way to understand ROS2 workspaces, nodes, topics, and DDS without drowning in commands

I almost quit ROS2 because none of the tutorials explained what it actually was.
They taught me commands, but never the system those commands were controlling.
ROS2 felt like a maze of terminals, build steps, and cryptic errors with no map.
Everything changed when I stopped thinking about ROS2 as software and started seeing it as a living system - a workspace filled with rooms, communication pipes, and active conversations.
Once I had that picture in my head, every command, node, and topic suddenly made sense.
This article is that picture.
The ROS2 Structure
A ROS2 workspace contains a src directory that holds all packages.
these packages can be setup with cpp or py. within their structure you create node code.
A single package can have 0-many nodes in it.
nodes may publish/subscribe(one method of communication) to various topics.
These topics are shared and anytime a topic is published then those that have subscribed to the topic may read and act upon it.
Nodes may be pub, sub or both. this might take the form of source(of information), relay(processing that info for consumption), sink(the end product cleaned up with an interface(possibly)
When a package has been created, developed and saved we need to go to the workspace.

A ROS2 workspace is the build and runtime boundary.
You can think of it as a workshop with multiple rooms. This is where we go to:
-BUILD it(colcon build ( - packages-select nameOfPackage)),
-SOURCE it (source install/setup.bash) and
-RUN it(ros2 run pkg_name exe_name.
I look at ros2(visually) is as a workshop with distinct rooms:

a knowledge room(src) that holds all of the packages,
a development lab where I modify the package contents and finally
a BUILD, SOURCE, RUN room that allows me to visualize the results. oh, yeah, there is also
an install room that holds all of the developed components for the BSR room to draw/pull from.

When dealing with packages or even performing BSR I will use ros2 commands such as colcon build, source install and others but also there is a CLI side of things that begin with ros2. Things like run, topic, node and these are used to interrogate ROS2 to discover its states, values, what is operational, etc.

A node graph is like a communications fabric that is stretched across a table. even with nothing on the fabric to take advantage of it there is still a communications network.
When we add a node to that fabric we have part 1 of a potential conversation. when we add another node and sync it up to the same communication channel as the first one then we have the breeding ground for communications.

ROS is the underlayment for everything.
The Middle Layer consists of RMW(ros middleware) and DDS(distributed data system)

As a Robot Overlord, I play on the Upper layer with the workspace, packages and BSR

If this helped:
❤️ React • 💬 Comment • 🔖 Save • 🚀 Boost • 🔗 Share
Follow for ROS2, robotics, and systems tutorials.

ROS2 SYSTEMS ANALYSIS: The Build-Source-Run Ritual

Eric Young — Mon, 19 Jan 2026 15:22:12 +0000

The Build-Source-Run ritual that turns dead packages into living systems

**
**I spent hours writing ROS2 nodes that "compiled fine" but refused to run.
Nothing was broken.

I was skipping the ritual that makes ROS2 come alive.

BUILD- From your workspace folder, compile your package. This generates all necessary executables, libraries, and setup files, storing them in the /install directory. (colcon build)
SOURCE- Load the environment so ROS2 can locate your package's components. (source install/setup.bash)
RUN- Launch your package's nodes. (ros2 run package_name exe_name)

Following the BUILD-SOURCE-RUN workflow correctly every time ensures your ROS2 packages execute reliably and avoids runtime errors.

ROS2 SYSTEMS ANALYSIS: Developing The Correct Mental Model

Eric Young — Mon, 19 Jan 2026 15:20:19 +0000

A simple mental model that turned constant DDS failures into a working system

I almost quit ROS2.
Not because it was hard - but because it felt incoherent.
Nodes would fail, topics would vanish, nothing behaved the way I expected, and every tutorial seemed to contradict the last.
I was doing everything "right"… and nothing was working.
The breakthrough didn't come from learning more commands.
It came when I realized I was holding the wrong mental model of what ROS2 actually is.
Once that snapped into place, DDS stopped feeling like black magic and ROS2 finally behaved like a system instead of a curse.
This article explains the model that fixed it.
There are two layers to ROS2 that most beginners never separate - and until you do, everything feels broken even when it isn't.
THE CORRECT MENTAL MODEL
**Finally, it came to me.
**I wasn't DEVELOPING THE CORRECT MENTAL MODEL
In order to create the correct mental model I had to identify that it has two distinct sections(that I care most about): the Big Picture and the ROS Picture.
**The Big Picture
**Robotics doesnt have to be rocket science or brain surgery, although it might mirror them closely.
To simplify it lets understand that ROS2 is built upon DDS(Data Distribution Service) and uses RMW(ROS Middleware) to communicate between the two:
DDS is a Data Distribution Service that is used by many sectors of our industry for reliable, peer-to-peer communication. Major transportation, the military and robotics all use it.
RMW (ROS Middleware) is the communication agent between ROS and DDS.
ROS2 is the successor to ROS1 which did NOT use DDS. It uses RMW to access DDS to facilitate message transport.

ROS is like a full-service working environment.
The Workspace- is the space within which you can develop, build and run your ideas.
The /src folder- is the library of all of the packages you have created.
When you move back into the workspace and:
BUILD- artifacts are created and stored in the /install folder of the package.
SOURCE- create the working environment populated with the artifacts and prepare it for the next stage.
RUN- this sets the ROS2 environment in motion allowing you to visualize the communications flow

If this helped:
❤️ React • 💬 Comment • 🔖 Save • 🚀 Boost • 🔗 Share
Follow for ROS2, robotics, and systems tutorials.

ROS2 SYSTEMS ANALYSIS: Bringing Nodes To Life

Eric Young — Mon, 19 Jan 2026 15:09:39 +0000

A story-driven explanation of packages, builds, installs, nodes, and the ROS2 graph

The Workshop
A robotics engineer walks into the knowledge wing of a robotics workshop.
Along the far wall stretches a long series of shelves, each one labeled with a domain:

navigation
sensing
control
communication

He is not looking for a single circuit or a stray line of code - he is looking for a capability. He finds the shelf marked for a distributed control graph, robot set 21a-3, and pulls the package down.
The package is not the machine. It is the place the machine's knowledge lives.
He opens it at a nearby workbench and finds the structures he expects -
the patterns of logic, the rules for how things will be built, the places where messages will be formed and sent.

He edits
He removes what no longer fits
He adds what the system will need tomorrow

When he is finished, he closes the package and returns it to its casing, now subtly but meaningfully changed.

He walks to the center of the room.
There stands a precise, quiet platform - the build dais. When he places the package on it and invokes the ritual, the workshop hums. The raw ideas inside the package are forged into something executable - something that can exist in the real system.
Along the far wall, a wide glass window begins to clear.
Where there had been fog, there is now a view into the installed world - a clean, coherent environment where the newly built machinery can be seen.
The engineer approaches the console.
He types the final command.
And the machine wakes.
Somewhere inside the workshop, a new presence announces itself.
It takes a name.
It declares what it can speak and what it can hear.
Invisible wires connect as other machines recognize it. The distributed graph reshapes itself around this newcomer.
Nothing dramatic moves - no gears spin, no sparks fly - but the system is now different. Something has joined it.
The engineer exhales.
This is not just running code.
This is giving a system a new voice.

- - - END - - -

If this helped:
❤️ React • 💬 Comment • 🔖 Save • 🚀 Boost • 🔗 Share
Follow for ROS2, robotics, and systems tutorials.