Robot operating software: connecting ROS 2 robots to your site systems

Robot operating software is the software that controls a robot and lets other systems work with it. It is usually several layers: the manufacturer’s own software and SDK, often an open framework such as ROS 2, fleet management software for groups of robots, and middleware that connects the robot’s work to the systems a site already runs.

An SDK (software development kit) is the set of tools and interfaces a manufacturer gives developers to program and control its robot. An API (application programming interface) is a defined way for one piece of software to ask another for data or to send it instructions. Most of the effort in getting a robot to do useful work on a site sits in these layers, not in the robot’s motors.

ROS 2 (Robot Operating System 2) is open-source software for building robot applications: libraries, drivers and developer tools that handle sensors, navigation and communication between a robot’s parts. Despite the name, it is not an operating system like Windows or Linux, and it does not connect a robot to warehouse or production systems on its own.

The official ROS 2 documentation describes ROS as a set of software libraries and tools for building robot applications. Underneath, ROS 2 is built primarily on DDS (Data Distribution Service), an industry-standard way for software components to discover each other and exchange data, and the ROS 2 middleware documentation lists other options such as Zenoh. A ROS 2 robot is one whose software uses that framework.

What ROS 2 does not do is decide which order to pick, report a fault to a maintenance system or open a building’s doors. Those jobs belong to the layers above it. ROS integration therefore usually means connecting ROS 2 topics and services to an integration layer, which then talks to site systems through their own APIs.

Robot middleware is software that sits between robots and a site’s systems and translates between them. It takes tasks from a WMS, MES or building system, turns them into instructions a robot understands, and sends back what the robot did and found. A site needs it so that robots from different makers fit one way of working.

Middleware in general means software that connects other software; DDS is middleware inside a robot, while robotics middleware at site level connects whole robots to business systems. A WMS (warehouse management system) runs stock and orders, an MES (manufacturing execution system) schedules and records production, a BMS (building management system) runs doors, lifts and plant, and a VMS (video management system) handles security cameras.

Robot APIs connect to site systems through software in between. The robot or its fleet manager exposes an API or SDK; the WMS, MES or BMS exposes its own API or a standard interface. An integration layer calls both, so a pick task becomes a robot mission and a completed mission becomes an update in the site system.

Many commercial robots expose a vendor API or SDK rather than native ROS 2, and what is offered varies by platform and by tier, so the robotics API on offer should be checked before purchase. On the site side, the question is which interfaces each system offers and in which version. Our guide to integrating a robot with the software you already run compares the four ways this can be done and what each locks you into.

Robot fleet management software runs a group of robots as one system. It assigns tasks, plans routes and traffic so robots do not block each other, sends robots to charge, and reports status. Most manufacturers supply their own for their own robots, so a site with robots from several makers needs a way to coordinate them.

Open-RMF, the Open Robotics Middleware Framework, describes itself as open-source software that enables sharing and interoperability between multiple fleets of robots and physical infrastructure such as doors, lifts and building management systems. It is one option for mixed fleets; fleet software of any kind still has to be connected to the site systems that create the work. More on fleets of wheeled robots is on our autonomous mobile robots page.

Before integrating a robot, ask what interfaces it exposes, which site systems it must reach, where its data goes, how it behaves when the network drops and how it will be secured. The answers decide whether the robot can become part of the operation or stays a separate tool with its own screen and its own login.

Forge Robotics starts from the task and the systems the robot’s work must reach, then matches a platform across manufacturers whose interfaces fit, whether that is ROS 2 or a vendor API. We plan a pilot that tests the connections as well as the robot, and can supply the robot where that fits the client.

Forge Anvil is being developed to bridge robot software such as ROS 2 and a site’s own systems (for example WMS, MES, BMS, VMS or alarm platforms) through APIs where possible. It is designed to run on the site network and keep robots part of the operation. Connections are scoped site by site in the integration review; read how Forge Anvil is designed to work, and how we structure a pilot programme. For warehouse sites, see warehouse and logistics.