The market for autonomous mobile robots - AMR for short - is booming. In 2020, the market size amounted to USD 356 million - and MarketWatch forecasts growth to USD 1011 million by 2026 at a compound annual growth rate (CAGR) of 15.9%.

Until recently, AGVs were the representatives of the latest technology with their ability to transport raw materials and unfinished and finished products to production lines or store and retrieve goods from warehouses and logistics centers. AGVs use a combination of software and sensor-based guidance systems to control their movements. They perform safe and reliable work when moving loads, as they work on a fixed route and have precisely controlled acceleration and deceleration as well as obstacle detection.

However, AGVs lack flexibility. If, for example, the layout of a production line changes, the track guidance must be adapted accordingly, which is usually time-consuming and costly. If an AGV detects an obstacle, it stops until someone removes the object. Furthermore, AGVs cannot interact with humans as the fleet management system is centralized and works without peer-to-peer communication.

AMRs are far more flexible: if an operational layout changes, simultaneous localization and mapping (SLAM) allows the robot to explore the as yet unknown space to automatically create a map without additional effort or cost to the contractor. AMRs use a range of sensor technologies and a combination of camera detection and real-time communication technologies to dynamically detect and avoid obstacles, including people.

A new direction

The Robotic Operating System (ROS) is an open source framework for the development of robotic software, i.e. neither a robot nor an operating system. ROS was developed in 2007 by two Stanford PhD students, Eric Berger and Keenan Wyrobek, with the goal of enabling software developers with minimal knowledge of robotics hardware to write software for robots.

Today, ROS Classic (ROS 1) provides numerous stable packages, tools and tutorials that include the hardware for developing various robotic applications. ROS building blocks include sensor fusion, navigation, visualization and motion planning.

Originally developed for academic use, ROS 1 assumes perfect communication. In practice, however, this is anything but perfect, especially in the industrial sector. Variable factors such as bandwidth, networking options, communication ranges and the transceiver power consumption of battery-powered mobile robots make it even more difficult to find optimal solutions. Furthermore, ROS 1 was only intended for use with a single robot. To make factories with multiple robots work smarter, collaboration capabilities are needed. This is where ROS 2 comes into play, which, based on the DDS communication framework, decentralizes the fleet management system by enabling real-time peer-to-peer communication - known as swarm autonomy - for AMR.

The migration from ROS 1 to ROS 2 enables swarm robotics autonomy.

© Adlink

A swarm of autonomous mobile robots can perform their tasks with little or no supervision from human operators. However, the industry will need to migrate from ROS 1 to ROS 2 to realize this goal. This migration is a challenge.

For developers already using ROS 1, there are three main challenges: Complexity, scalability and upgradeability. AMR design is complex. To build a robotic system, users must select and purchase the hardware and install the software (the operating system (OS), drivers and packages), from computer platforms to sensors, motion controllers and mechanical design. If they are not familiar with a system, it can take up to a month to complete the system integration. If advanced functionalities such as real-time capability or dedicated Quality of Service (QoS) are required, the developer must write the code themselves. If a robot is built as a feasibility study, the issues of scalability and deployment pose greater problems.

ROS 1 is not designed for communication across multiple AMRs. In such cases, there would be a risk of accuracy problems, failures or damage to the fleet system. In addition, ROS 1 support will reach end of life (EOL) by 2025; affected companies must decide how they want to manage the migration from ROS 1 to ROS 2.

ROS 2 is the update that transfers ROS 1 from the academic world to the industrial sector. ROS 2 enables industrial use with multiple collaborative robots and reliable, fault-tolerant real-time communication. With DDS as the backbone, ROS 2 provides a unified data exchange environment (such as a data flow) that enables an AMR swarm to communicate. Additional devices with Distributed Data Service (DDS) technology can also use the data flow to share data.

DDS is a key component of ROS 2, and at the core of the technology is the Data-Centric Publish-Subscribe (DCPS) standard, which provides a global data space that can be accessed by all independent applications. The United States Navy used ROS 2 to solve the compatibility problems that arose in the course of extensive software upgrades in the complex network environment of ships. Since its release by the Object Management Group (OMG) in 2004, DDS has become the standard solution for the data publish-subscribe pattern for distributed real-time communication in autonomous and sophisticated systems.

The right AMR solution

There are several aspects to consider when looking for the right ROS 2-based AMR solution.

Companies must first determine whether the systems are optimized for AMR navigation, including hardware and software integration, to avoid time-consuming dependencies, version issues and compilation errors.

To achieve high accuracy in sensor fusion, time synchronization of several integrated sensors, for example GMSL (Gigabit Multimedia Serial Link) images and Inertial Measurement Unit (IMU), is essential.

To optimize internal data processing, the system should have a shared memory mechanism. In conventional implementations, processes in the system have to forward messages via the network level of the operating system, which leads to latencies. Access to shared memory and direct transmission are optimized approaches that significantly reduce latencies.

The solution developed should enable decentralized communication, support the autonomy of the swarm and at the same time ensure fault tolerance and redundancy.