Open-source in robotics: ROS as a faster path to the first prototype

When the conversation turns to robotics in manufacturing or logistics, it usually follows one of two paths. The first: an integrator is hired, a closed platform is purchased, and a year later the company finds that any change costs as much as a small project. The second: the whole thing gets postponed to better times because "it is too expensive and unclear".

Between those two options there is a third, which has become increasingly practical over the past few years. Its foundation is an open stack, and specifically the Robot Operating System - ROS.

I am not going to argue that open-source is an ideology. Here I treat it as a tool for lowering the cost of the first experiment. The business case for robotics - and why the right count should go beyond headcount reduction to flow predictability - shapes what an open stack experiment needs to prove.

What ROS is and why it was built

ROS is not an operating system in the usual sense. It is a collection of libraries and tools that gives the components of a robot a shared language: sensors, actuators, navigation algorithms, cameras, manipulators. It emerged from academic work at Stanford and Willow Garage as the answer to one concrete question: why does every research group write the same basic pieces from scratch?

The principle is simple. Instead of a monolith, there is a graph of nodes communicating through standardised messages. This lets you swap one component without touching the others. You can replace a navigation algorithm without rewriting the camera driver.

By 2012 ROS has a reasonably mature community around it, a package repository with hundreds of ready-made components, and documented use on real hardware - not just in labs.

Why this matters for a company thinking about a pilot

The most expensive moment in any robotics project is not the full rollout - it is the first prototype. That is where you find out whether the idea works at all. That is also where money disappears most often.

An open stack changes the economics of this stage for several reasons.

First, ready-made components. Localisation and mapping algorithms, drivers for common lidars and cameras, manipulator control stacks - these already exist and are being used by other teams. You do not have to pay to build something that is already there.

Second, vendor independence during the experiment. When a prototype is assembled on an open stack, the decision about which hardware to commit to can be deferred. This matters: early lock-in to a vendor is what closes off cheaper alternatives.

Third, hirability. Engineers who know ROS exist in the market. It is not an exotic skill.

Where the limits are

Open-source in robotics is not an answer to every question. There are situations where it is the right fit and situations where it creates more problems than it solves.

It works well when:

• you need to test a hypothesis quickly or build a demonstration rig;
• the team has the engineering capacity to maintain and extend the stack;
• certification and reliability requirements are not critical at this stage.

It works poorly when:

• there are no engineers willing to work with open code;
• industrial reliability and 24/7 support are required from day one;
• the company wants to buy a solution and stop thinking about it.

The transition from prototype to full deployment almost always requires a different conversation - about support, certification, SLA. But that conversation comes after the idea has been validated.

Questions to ask before a pilot with an open stack

Before starting a prototype, I usually ask a handful of questions:

1. What exactly are we testing with this pilot - technical feasibility or business value?
2. Do we have an engineer with ROS experience, or are we counting on an outside contractor?
3. What hardware do we have or plan to use - and how compatible is it with an open stack?
4. What is the real budget for this experiment, and what will count as success?
5. If the pilot succeeds - who owns the system going forward?

These questions are not about the technology. They are about whether the organisation is ready for the kind of work an open stack implies. If the answer is "not really", it is better to know that before spending the money and time.