MassRobotics Interoperability Standard built into LocusOne Warehouse Execution Platform

I suggest that we consider building in the MassRobotics Interoperability Standard 1.0 into LocusOne Warehouse Execution Platform. For the following reasons, which are some, but not all the reasons we might want to do so:

• Some customers are already demanding that bots are interoperable with other AMRs and equipment and the MassRobotics standard is the one most likely to be requested

• There is a halo effect to being cooperative for the customers' benefit; as opposed to taking the position of a closed, proprietary company / technology / solution

• We can use the standard to improve performance of our own fleet if there are heterogeneous fleets, or other equipment that uses the standard in a building

• If our fleet manager can show the location and status of other bots or equipment in the building, then our fleet manager and dashboards can continue to be the primary user interface and define the user experience for our customers

• We can collect data on what other bots from other companies are doing and we can aggregate it with our own data

  • we can understand what other bot companies are doing (or not doing)

  • we can measure / show our bots performance relative to theirs

  • we can capture the data needed to understand of other systems are affecting the performance if our system

• We can keep third party fleet managers from gaining a foothold with our customers

• We can use the interop standard for our own purposes such as what's described in the MHE deconfliction idea

• We could create (and monetize) accessories or services utilizing the standard, which could be used by other companies, or keep them for ourselves.

• We can establish a foundation with the 1.0 standard so that if we opt to implement subsequent standards, like the 2.0 standard that is in the works right now, it will not be such a heavy lift

  • There will most likely be standards established in the future that enable another company's fleet manager or a third party fleet manager to control bots that don't have their own fleet manager or aren't able to meet customer needs in a particular market or use case.

  • If this comes to pass, we will want to be the fleet manager handing out instructions, not the one taking orders.

  • Building 1.0 into our production system would establish credibility that Locus is the best company to be THE higher level fleet manager, as opposed to some third party company offering a universal fleet manager.

Simply put: We might not want to be in the business of building the "high level fleet manager" but we most definitely don't want to be in a position to have some outside "high level fleet manager" come between us and our customers; the Interop 1.0 standard provides the framework to stop that conversation in its tracks. If a customer comes to us and says "we want to use [fleet manager x]" then we can immediately say "why would you do that when LocusOne has that capability already built in?"

https://www.massrobotics.org/autonomous-mobile-robot-standards-published-by-massrobotics/

https://github.com/MassRobotics-AMR/AMR_Interop_Standard

https://locus-robotics.ideas.aha.io/ideas/LSA-I-362