Building a robot from scratch is a bit like deciding to cook a multi-course dinner using only a single frying pan and the firm belief that recipes are for people who lack creativity. You can absolutely produce something edible. Maybe even something impressive.
Robotics gets complicated in the same way. A motor and a sensor? Manageable, but adding cameras, LiDAR, mapping, navigation, and multiple systems that need to communicate, and suddenly your little project needs a proper kitchen. ROS 2 is the well-stocked kitchen that most serious robot builders eventually admit they needed. But that creates another question: do you need the entire kitchen before you've even learned how to make toast? Probably not. Which brings us to your first robot.
So You Want to Build a Robot... Cute.
Let's establish something before ROS 2 enters the conversation.
You absolutely do not need ROS 2 to build your first robot. A line-following robot can happily spend its entire existence without knowing what a ROS node is. An Arduino, a couple of IR sensors, a motor driver and some questionable wiring decisions can get the job done.
The same applies to plenty of beginner projects:
· Obstacle-avoiding robots
· Bluetooth-controlled cars
· Basic robotic arms
· Sensor-based automation systems
· Simple Raspberry Pi robots
For these projects, adding ROS 2 can actually create unnecessary complexity. You don't need an entire communication framework when one controller can comfortably handle the job.
But robots rarely stay simple once you get ambitious. Add a camera, LiDAR, mapping, localization and navigation, and suddenly the challenge isn't controlling one component, it's coordinating several of them at the same time. That's the point where ROS 2 starts making sense.
What Is ROS 2, and Why Is It Everywhere?
Despite the name, the Robot Operating System isn't actually an operating system in the same sense as Windows, Ubuntu or macOS.
ROS is an open-source collection of software libraries, tools and conventions for building robotic applications.
A useful way to think about ROS 2 is as the group chat of your robot. Without it, every subsystem has to figure out how to communicate with every other subsystem. With ROS 2, you can break a large robotic system into smaller programs called nodes, then give those nodes standardized ways to exchange information.
Camera node → Object detection node → Navigation node → Motor controller
Instead of writing one enormous program called final_robot_REAL_final_v7_working.py, you create smaller pieces with specific responsibilities.
ROS 2 primarily provides three communication styles: topics, services and actions. Topics are designed for continuous streams such as sensor data; services handle short request-response interactions; and actions suit longer-running tasks that may provide feedback and need cancellation.
Companies shipping warehouse robots, research labs running robot fleets, and teams developing everything from agricultural robots to inspection platforms can benefit from the same reusable building blocks. Developers can also build on an existing ecosystem of packages for capabilities such as navigation, visualization, robot modelling, and sensor integration instead of recreating every piece themselves. Because once the alternative becomes writing your own communication layer, managing coordinate transforms, building visualization tools, and debugging all of it from scratch, the “Why is ROS 2 everywhere?” question starts answering itself.
Can We Build a Robot Without It?
Yes. Plenty of working robots have never heard of ROS 2.
A line-following Arduino bot with two motors and an ultrasonic sensor does not need a middleware framework. A drone flying PX4 or ArduPilot already has a domain-specific stack optimised for its job. Industrial arms often run proprietary or PLC-based systems. Lightweight messaging libraries or plain shared-memory C++ can move data fast enough for many embedded projects. If your robot lives on a single microcontroller, does one clear task, and will never grow beyond a few sensors, forcing ROS 2 into the picture is like hiring a full orchestra to play a three-note ringtone.
The calculus changes the moment the system becomes complex. Multiple sensors that must stay synchronised. A navigation stack that has to fuse lidar, odometry, and maps. Code that needs to be shared across team members or platforms. Requirements for logging, replay, visualisation, and eventual production hardening. At that point the “I can just write it myself” path starts consuming months that the ROS 2 ecosystem already spent for you. You can still build without it. You will simply rebuild a lot of the same infrastructure under a different name, usually with fewer debugging tools and a smaller community when things go sideways at 2 a.m.
How Much ROS 2 Do I Need Before I Can Touch Grass Again?
Not as much as the documentation volume suggests, and more than the five-minute “hello world” tutorials pretend.
You need a working mental model of nodes, topics, services, and parameters. You need to be able to create a package, write a publisher and subscriber (Python is the kinder starting language for most people), launch a few nodes together, and inspect the graph with the available tools. You should understand the idea of a TF tree so coordinate frames stop being pure mystery. Beyond that, depth comes from the specific domain: navigation packages if you are building mobile robots, manipulation stacks if arms are involved, simulation workflows so you can break things without smoking real hardware.
The goal is not encyclopaedic mastery. It is fluency with the interfaces so you can plug existing high-quality packages into your system and only write the parts that are unique to your robot. Most working robotics engineers are not ROS 2 core developers. They are people who know enough of the framework to stop fighting the infrastructure and start solving the actual robotics problems. That threshold is reachable without disappearing into a cave for a year. It does require deliberate practice, building small systems that grow, reading error messages instead of immediately searching for a different tutorial, and accepting that the first three times you try to get two nodes talking will feel personal.
Where to Start?
Start with a clear, small robot behaviour you actually care about, not a list of every ROS 2 concept. Install a current long-term-support distribution on a supported Ubuntu release. Create a workspace. Make two nodes talk to each other about something trivial. Then add a third. Visualise the graph. Break it on purpose and fix it. Move into simulation once the basic communication feels less alien. Only then bring in higher-level packages.
Keep the hardware simple at first. A differential-drive platform or even a simulated robot is enough to learn the patterns that transfer. Treat the ecosystem packages as black boxes whose interfaces you learn, not as code you must understand line-by-line on day one. The engineers who progress fastest are usually the ones who treat ROS 2 as a set of reliable tools rather than a mountain that must be climbed in a single heroic weekend.
Building robots will still involve moments when the machine stares back with the digital equivalent of a shrug. The difference is that those moments become shorter and less frequent when the communication, tooling, and reusable algorithms are already solved problems. The question was never whether ROS 2 is mandatory for every possible robot. It was whether you want to keep reinventing the same infrastructure every time the project grows past the “cute demo” stage.
Most teams that ship robots past the prototype phase eventually discover that a structured path through the framework turns the late-night debugging sessions into something closer to engineering and further from archaeology. When that path is laid out with clear milestones and practical projects, the robots still misbehave. They just misbehave in mor
