Avoiding “Vendor Lock-In’’ with Warehouse Robotics

Recently, the Roboteon team was introduced to a new term by a prominent figure in the robotics sector, who shall go nameless.

The term is “vendor lock-in,” and the concept refers to something we’ve been writing and speaking about from the start of our company, but lacked this punchy two-word summary that so well captures the issue, which is this:

If companies don’t choose wisely relative to robotic software, they can significantly limit their future robot options, and/or significantly add to the cost of future projects.

Every Autonomous Mobile Robot (AMR) will come with a Fleet Management Systems, or FMS. This software enables at minimum the following functions:

• Scan the environment over the course of hours or days to create a digital map of the facility that will deploy the robots.

• When work is needed from the mobile robot, navigate the robots from point A to point B, considering the fastest travel path factoring in distances, congestion, and other variables.

• Move the robot in a safe fashion, with collision avoidance technology for keeping people, other AMRs, and additional equipment and fixtures accident free.

• Provide some mechanism for integration with IT systems, generally through an Application Programming Interface, or API.

While these four core capabilities will be available from the AMR provider, robot OEM software functionality varies widely from there, some with decent functionality to little or no additional capabilities for supporting fulfillment and other tasks with their robots.

However, system architects need to be careful here. Robot hardware vendors in general are not much interested in making it easy or even possible to add robots from a different OEM, subjecting you to “vendor lock-in.”

Let’s look at what should be a common operational scenario going forward. Suppose a given company buys 25 AMRs to support collaborative picking. But a couple of years later, the company has a need for additional AMRs due to growth, perhaps as a result of an acquisition.

However, now there is another AMR from a different OEM that the company prefers for cost, design or other reasons. With interoperability, the company would be able keep AMRs it has and seamlessly add the new AMRs to the existing fleet.

But here interoperability means even more. In addition to basic integration, the company will want to manage the robots from both manufacturers together for visibility, task assignment, performance measurement and more, operating all of them as if it is a single fleet.

If that can’t be easily achieved, then a company faces several unattractive options:

• Add the new robots from the current vendor, even though another OEM is preferred

• Somehow run parallel systems, each dedicated to a specific fleet

• Spend a large sum of money trying to integrate both fleets (and possibly others down the road)

The better choice: with the first robot deployment, let the vendor’s FMS manage the core functions described above, and rely on an independent software solution such as the Roboteon Robotics Fulfillment Platform that can provide – among many other capabilities – the desired interoperability across different vendors.

That means you get the opposite of vendor lock-in: complete flexibility to add more robots of the same type the company from a different vendor. A company with this platform can also connect the workflows of the current vendor with different workflows from other types of robots. This enables  vendor-agnostic, multi-functional robot orchestration for executing tasks on the work floor.

The analysts at Gartner call this type of software a Multiagent Orchestration (MAO) platform, and at Roboteon we like to think we deliver all the capabilities considered part of this framework and more – MAO+.

Robotics vendor lock-in – not good. Consider the adaptable software platform solution instead to send expensive vendor lock-ins packing.

Let’s talk about your opportunities.