1. What ROS 2 is, and when not to use it
The problem it solves
One robot has many parts that must talk to each other — motors, encoders, LiDAR, camera, emergency stop, path planner.
Write it all as one program and you will always hit these three:
Problem |
Example |
|---|---|
One part hangs, everything hangs |
LiDAR stops responding → main loop stalls → the stop command never reaches the wheels |
Changing hardware means rewriting |
New LiDAR brand, and you edit the whole file |
You cannot see inside |
The robot will not move, and you cannot tell whether the command never arrived or arrived and was ignored |
ROS 2 solves this by splitting the system into many small programs (nodes) that send messages to each other over named channels (topics).
What you actually get:
LiDAR hangs → other nodes keep running, the stop command still goes out
New LiDAR → replace that one node, as long as it publishes the same message type
You can watch the data on any channel without touching the code — this is the one that matters most when something is wrong
What it costs
It is not free. What you trade away:
A lot to learn — workspaces, packages, launch files, tf, QoS. Getting a wheel to turn the first time takes far longer than writing it directly.
Locked to an Ubuntu version — each ROS 2 release supports exactly one, and choosing wrong at the start is painful to undo
Added latency — messages go through a communication layer rather than a direct function call. Microsecond-level control is not what ROS 2 is for.
Harder debugging at first — some failures are completely silent, with no error at all (see topic 10, QoS)
When you should not use it
Important
ROS 2 is not always the better choice. These three jobs are simpler and more reliable written directly.
① A conveyor or machine that repeats a fixed path No path planning, no need to know where it is — one PLC or microcontroller is enough. Adding ROS 2 adds something to maintain and gives nothing back.
② Control loops that need millisecond accuracy Motor current control, wheel PID, over-current cutoff. These belong in the drive or a microcontroller, not across ROS 2. In a real system ROS 2 commands a velocity and the drive handles current itself.
③ Safety systems The emergency stop and safety scanner must be a hardware circuit that cuts power on its own. Never let software be the only thing that stops the robot — ROS 2 or otherwise. ROS 2 can know the state; it must not be what cuts.
When it does pay off
The simple answer: when the robot has to know where it is and decide for itself where to go.
At that point you need mapping, localization, path planning, and obstacle avoidance. Writing all of that yourself takes years. ROS 2 has it already, proven in real use.
The version this guide uses
ROS 2 Humble on Ubuntu 22.04 — chosen because Nav2 and slam_toolbox are
most stable there at the time of writing, and it is supported until 2027.
Warning
ROS 2 is tied to an Ubuntu version and it is not easy to change later. Install the wrong Ubuntu and you cannot install Humble at all — you have to reinstall the OS. That is the next topic.