The world is quickly changing for modern warehouses. E-commerce companies, retailers, hospitals, and other third-party logistics businesses view autonomous mobile robots (AMRs) as a critical technology to rein in high labor costs and increase throughput to reduce fulfillment time. Factory owners and managers want quick AMRs that are easy to deploy with the ability to be modified on the fly. Unlike its predecessor, the automated guided vehicle (AGV), an AMR can understand commands and dynamically detect and avoid obstacles to navigate through different work environments without being on a direct path or having an operator control its movement. This article describes developing and deploying AMRs with integrated hardware and software technology, and includes use cases for factories, smart cities, and hospital

Sophisticated warehouse demands drive the megatrend from AGV to AMR

The AMR market is booming. In 2020, the market size was $356 million. MarketWatch predicts that it will grow at a compound annual growth rate (CAGR) of 15.9% to $1011 million by 2026. Manufacturing and logistics enterprises’ demand high throughput, quick and easy robot deployment, and flexible production lines. This trend, accompanied by the emergence of new applications, is driving a major movement from automated guided vehicles (AGVs) to AMRs. To understand the megatrend from AGVs to AMRs, let’s examine the two technologies.

Automated Guided Vehicle (AGV) vs. Autonomous Mobile Robot (AMR) – Key Differentiators

Until recently, AGVs represented the latest advanced technology – capable of transporting raw materials, works-in-process, and finished goods to manufacturing production lines or storing and retrieving goods in warehouses and logistics centers. AGVs use a combination of software and sensor-based guidance systems to direct their movement. They are safe and reliable at moving loads because they follow a fixed path with precisely controlled acceleration and deceleration and obstacle detection bumpers.

However, AGVs lack flexibility, (see figure 1). If a production line layout changes, for example, this means that the guidance track infrastructure will need rerouting, which often involves time and money. When an AGV detects an obstacle, it stops until someone manually removes the item. Furthermore, AGVs cannot interact with humans because the fleet management system is centralized without peer-to-peer communication.

AMRs are far more flexible. If an operational layout changes, simultaneous localization and mapping (SLAM) let the robot explore the unknown space to create a map automatically without extra effort or cost to the operator. AMRs can use an array of sensor technologies to detect and avoid obstacles dynamically, including people. These robots use sensors and a combination of camera detection and real-time communication technologies, enabling real-time collaboration with humans.

A new direction: the migration from ROS 1 to ROS 2 enables swarm robotics autonomy

The Robotic Operating System (ROS) is an open-source framework for robot software development that is neither a robot nor an operating system. ROS was created in 2007 by Eric Berger and Keenan Wyrobek, two Stanford Ph.D. students who wanted software developers with minimal robotics hardware knowledge to write software for robots.

Today, ROS Classic, now referred to as ROS 1, has abundant stable packages, tools, and tutorials that encapsulate the hardware for developing different robotic applications. ROS building blocks include sensor fusion, navigation, visualization, and motion planning.

Originally developed for academic use, ROS 1 assumes perfect communication. In the real world, communication is less than perfect, especially in an industrial setting. Variable factors, such as bandwidth, networking possibility and communication range, as well as transceiver power consumption for battery powered mobile robots add additional complication. Furthermore, ROS 1 was only intended for use with a single robot. To make factories more intelligent when there are multiple robots, they need collaboration. Based on the DDS communications framework, ROS 2 decentralizes the fleet management system by enabling AMRs to communicate in real-time in a peer-to-peer way, called swarm autonomy.

The shift from AGV to AMR and the transition from ROS 1 to ROS 2 is likely partially caused or driven by factory manager priorities. In modern smart factories and warehouse and logistics centers, factory managers want higher throughput. They want AMRs that are efficient and capable of performing additional tasks. Owners also want quick and easy deployment, meaning they need an AMR to upscale operations fast without the need to pre-install infrastructure. They also need the flexibility to modify the production line, adjust settings in real-time, and perform these tasks easily. For these reasons, while many developers use ROS 1 for AMR prototyping, there is a trend to migrate to ROS 2.

Challenges when building next-generation, ROS 2 AMRs

The future of AMRs is swarm autonomy. A swarm of autonomous mobile robots can carry out their jobs with little to no oversight by human operators. To achieve this, the industry must move from ROS 1 to ROS 2.

However, migrating to ROS 2 is challenging, especially when developing and deploying a swarm of AMRs. For developers already using ROS 1, there are three main challenges: complexity, scalability, and upgradability.

The design for AMRs is complex. To build a robotics system, you need to select and buy the hardware from computing platforms to sensors, motion controllers, mechanical design, and install the software (the operating system (OS), drivers, and packages). If you are unfamiliar with a system, it might take up to a month to complete system integration. If you need advanced capabilities such as real-time capability or dedicated quality of service (QoS), the developer has to develop the coding by themselves. Once a robot is built for proof-of-concept, scalability and deployment become bigger concerns.

ROS 1 wasn’t built with the intention of being used for communication across multiple AMRs; doing so increases the risk of accuracy issues, failures or damages to the fleet system. Operators need to be able to rely on large-scale AMR deployment without exorbitant costs to execute.

Support for ROS 1 is expected to End of Life (EOL) by 2025, meaning more companies will need to determine how to migrate from ROS 1 to ROS 2. To do so, developers need to familiarize themselves with the migration process.

 

Considerations when implementing AMRs with ROS 2

ROS 2 is the update that takes ROS 1 out of academia and into the industrial realm. ROS 2 permits industrial use through multi-robot collaboration and reliable, fault-tolerant real-time communication. ROS 2, using DDS as a backbone, provides a uniform data exchange environment, like a data river, so a swarm of AMRs can communicate with each other. Additional equipment that adopts Distributed Data Service (DDS) technology can also use the data river to share data collectively.

DDS is one key component to ROS 2. The core of its technology is the Data-Centric Publish-Subscribe (DCPS) standard, which provides a Global Data Space that all independent applications can access. The United States Navy used ROS 2 to solve the compatibility issues with large-scale software upgrades in the complex network environment of ships. Since its release by the Object Management Group (OMG) in 2004, DDS is widely adopted as the standard solution for data publishing and subscription for distributed real-time communication within autonomous and demanding systems.

There are several considerations when looking for the right ROS 2-based AMR solution.

  • First, you must determine whether systems are optimized for AMR navigation—including hardware and software integration – to avoid time-consuming dependencies, versioning issues and compile errors.
  • To achieve high accuracy with sensor fusion, time synchronization from multiple integrated sensors e.g. GMSL (Gigabit Multimedia Serial Link) images, IMU (Inertial Measurement Unit) is vital.
  • To optimize the internal processing of data, consider whether the system features a shared memory mechanism, (see figure 3). In traditional implementations, processes in the system need to pass messages through the OS network layer, which incurs latency. Accessing shared memory and performing the transmission directly is an optimized approach and lowers latency significantly.
  • Find a solution that can provide decentralized communications, which would support swarm autonomy while ensuring fault tolerance and redundancy.

Figure 3. Inter-process communication optimization using a shared memory mechanism

Finally, consider if the solution is easy to implement. Some vendors provide software development kits (SDKs) with optimized DDS performance to support a swarm architecture and ensure reliable communication. Eclipse Cyclone DDS is a fast and reliable DDS implementation selected by the ROS 2 Technical Steering Committee (TSC) as the default ROS middleware (RMW) for the ROS 2 Galactic Geochelone release. This default configuration works for most developers; however, they can also use non-default RMW configurations.

For easier implementation and faster deployment, search for vendors that offer an integrated development environment (IDE), apps with tested and verified packages, and sample code for reference designs. To help the developer move from ROS 1 to ROS 2 easily, some vendors provide a migration guide that includes different approaches and describes the benefits and issues associated with the migration process.

ADLINK and Foxconn form FARobot® for swarm autonomy

ADLINK is currently working with global manufacturing giant, Hon Hai Technology Group (Foxconn). Foxconn used AGVs in their production facilities but they wanted to improve the flexibility of their production lines. Foxconn formed a joint venture with ADLINK, called FARobot®, to develop advanced swarm robot system (SRS) and autonomous mobile robot (AMR) solutions using ROS 2, (see figure 4).

Figure 4. The FARobot AMR robot can boost industrial efficiency and productivity 

As AMRs communicate with each other in real-time, they can perform task scheduling and assignment and use peer-to-peer communication to determine the location path for each ARM. If there is a fault in one of the AMRs, the fleet will initiate a backup immediately and automatically send the most suitable robot to assist.

FARobot’s unique AMR solution features swarm collaboration, task failover, and performance optimization. By adopting the latest swarm autonomy technology, a FARobot AMR robot can boost industrial efficiency and productivity – for example, delivering the right raw material or components to the right place at the right time to reduce unnecessary hold-ups.

Factory of the future: private 5G with DDS for real-time integration

The Fair Friend Group (FFG), one of the largest machine tool manufacturers globally, realized that labor shortages and changes in demands required an urgent need for logistics upgrades, inspection improvements, and enhanced technical services. While the company used AGVs, they wanted to improve flexibility for greater efficiency and to reduce costs. FFG teamed up with ADLINK and the Institute for Information Industry (III) to plan construction for smart factories.

When deploying smart factory solutions, you must account for manufacturing flexibility, factory expansion, and speedy line switches. In those environments, communication is key; DDS can act as middleware for both wired and wireless manufacturing environments and those with multiple wireless technologies. Featuring high reliability, DDS combined with private 5G low-latency and high-speed transmission enhances the sensitivity and response speed of AGVs

The first implementation of swarm autonomy was on industrial-grade spray gun production lines at the factory of FFG-member Anest Iwata, located in the Hukou Township, Hsinchu County, Taiwan. The Production Equipment and Operations Surveillance Center incorporated private 5G with DDS for real-time integration with production line information and to connect with AMRs to transport parts and components to multiple inspection divisions for enhanced productivity, (see figure 5).

Figure 5: Real-time integration with production line information and connection with AMRs for transportation. 

The implementation includes three significant technology applications: an AMR solution, automated optical inspection (AOI), and augmented reality (AR) smart glasses. The combination increased the factory’s yield rate by 15% and reduced production costs by 20%.

The future of AMRs

As the demand for swarm autonomy with peer-to-peer communication increases, industries will continue the trend to move from AGVs to AMRs and from ROS 1 to ROS 2. ROS 2 is a breakthrough aiding AMR development and deployment, covering a wide range of applications beyond industrial settings.

The recent pandemic introduced AMRs into the healthcare sector to automate the disinfection of wards and intensive care units. AMRs can also provide patient support and mobility assistance. There are AMRs in the retail industry, in-store and restaurant service robots, and autonomous last-mile delivery services for smart order fulfilment. Other applications include autonomous farming and smart harvesting, construction, industrial cleaning, and disaster recovery.

The development and deployment of AMRs take more effort than can be completed by a single company. It takes an ecosystem of collaborating partners with real-time software and hardware platform suppliers, sensor and system integration providers, and applications end-users. ADLINK supports developers by integrating hardware and software with communication technologies to enable them to build and deploy AMRs, quickly, flexibly and more cost-effectively in private 5G environments.