AMR Challenges – Interoperability

Every industry has its elephant in the room, and AMRs are no exception. One of the most prominent of them is AMR interoperability.

In our second blog post, about the safety challenges of deploying AMR’s, we tackled the issue of AMR interoperability from the safety aspect (even referencing a cute video of Star Wars’ R2D2 epic robot fight with R3F6 to depict the subject at hand).

Reality is not as dramatic, but it’s quickly becoming problematic. Fully autonomous mobile robots are supposed to be the next- generation of mobile task execution that addresses challenges of the operation floor of the future. But what do you do if this floor is populated by two, three, even four different types of mobile robots?

This isn’t science fiction. It is happening today, especially in the post-Corona world. A hospital may have temperature-taking robots, food distribution robots, and cleaning robots - all moving in the same space at the same time.

A production floor may have a picking robot, forklift robot, cleaning robot, and security robot – all fulfilling different tasks simultaneously. This begs the question, how do you optimally synchronize these different robots?

The Limits of Localized Intelligence

When you look at existing AMR technologies (we actually counted and there are about 300 companies developing AGVs and AMRs), you can see they have marginal technological differentiation. All are designed in a similar way and suffer from the same shortcomings: sophisticated and expensive platforms that are complex to manage and even harder to scale.

If you look under the hood, all AMRs have plenty of hardware components that enable autonomy, and expensive software to manage all functionalities. This includes sophisticated navigation systems, processing units, sensors, cameras, and so on, installed on each robot. These systems turn the robots into intelligent yet prohibitively expensive machines (a topic we covered extensively in our first post in the series).

Furthermore, since each AMR type is normally produced by a different vendor, they run on different operating systems, navigation systems, and fleet management systems. All this makes operating different robots and systems on a single floor a very complex task.

In fact, the few attempts to find a solution to the interoperability problem centered on developing a fleet management software compatible with a number of AMR vendors; or alternatively, finding ways for the AMRs to ‘talk’ to each other through a common API (that would enable communication between the different operating systems).

The Power of a Central Brain

Many times, we see in nature animals that appear to move as if directed by central intelligence. Hundreds and even thousands of individual animals acting in a highly organized manner; from bird flocks to fish schools to bison herds. The idea of a seemingly all-knowing ‘central brain’ creating impeccable synergy is compelling, and is what inspired us to move away from what we call a localized AMR brain to a central AMR brain.

Taking an example from the natural world, we envisioned the future industrial floor with multiple AMRs of different functionalities (forklifts, pickers, cleaning, security, etc.) all running in tandem on one, platform agnostic, software. No need to synchronize different systems so they operate together smoothly, no software bottleneck problems.

We realized that if we took the individual brain out of each robot, together with its navigation systems, processing units and other expensive hardware components, and moved them to an external central brain and eyes, we could overcome AMR challenges — including interoperability.

In fact, this new paradigm opens the door to many new exciting possibilities. Stripped of their expensive hardware components, AMRs become affordable to many new industries and sectors, bringing the threshold to autonomy incredibly low. What’s more, our paradigm is easily scalable: every mechanical pallet jack, cart or trolley could potentially be retro fitted to become a fully autonomous robot.

The ABC's of the Musashi AI Architecture

Musashi AI’s central brain is our Central Control Tower that can operate on any floor. We call this brain MAESTRO. Whether in a factory, a logistics warehouse, a shopping mall, a hotel or a hospital — MAESTRO can navigate and manage a fleet of different autonomous mobile robots.

MAESTRO agnostic AMR management platform takes full control of a very lean AMR, stripped of most of its complex and expensive hardware components. A grid of simple cameras installed on the ceiling transmits discrete images to MAESTRO, which rectifies and fuses the visual data to create a live “world map” of the facility.

MAESTRO uses this map to conduct the robot’s task generation, task allocation, navigation, route optimization, and fleet management. No need for expensive hardware on each robot. The robots are fitted easily with a generic hardware component that connects to MAESTRO via an open API.

MAESTRO does not interfere with the actual work of the AMR, such as cleaning. It merely functions as the task allocator, optimizer, and navigator and is agnostic to the specific task performed.

And what about existing AMRs? They can communicate with MAESTRO, which can fetch tasks, report location, assist them in optimizing their route and perform other related services.

Communication is done via Wi-Fi and requires minimal changes to the AMR controllers. In fact, since most AMRs are based on ROS (robotic operating system, sort of a Windows for mobile robots) they can integrate easily with MAESTRO (ROS has a seamless API with DDS, our communication protocol).

The XYZ's of the Musashi AI Architecture

Based on the visual map it puts together, MAESTRO sends each lean AMR from point A to point B through the optimal route (shorter, less obstacles), navigating each AMR on the floor in real time.

It’s an affordable and seamless infrastructure used to facilitate real autonomy — moving from an expensive, standalone AMR to a super affordable, lean and agile AMR fleet that’s interconnected and interoperable.

In essence, we are proposing a new evolutionary path to AGVs –an affordable solution based on a simple infrastructure for a high level of autonomy.

Maestro@634.ai