The MassRobotics Autonomous Mobile Robots (AMR) Interoperability Working Group was formed in 2020 to improve the use and adoption of autonomous mobile robots. This group, comprised of AMR vendors, engineers and AMR end-user companies, has published a consortium-built standard to guide robotic automation interoperability and take a step toward this future. The standard will allow robots of different types from various vendors to share status information and operational conventions or “rules of the road” so they can better coexist on a warehouse or factory floor.

The group has been meeting at least monthly for over a year and discussing several technical topics, agreeing on the following purpose and goal:

The group’s mission is to develop standards that will allow organizations to deploy autonomous mobile robots AMRs from multiple vendors and have them work together in the same environment, better realizing the promise of warehouse and factory automation. These standards will allow autonomous vehicles of different types to share information about their location, speed, direction, health, tasking/availability, and other performance characteristics with similar vehicles so they can better coexist on a warehouse or factory floor.

The AMR Interoperability Working Group is narrowly focused and will not address safety standards of AMRs and will not duplicate the efforts of ISO under the TC 299 WG (TS 15066, 18646, etc.), the IEEE RAS (such as 1872-2015 or 1873-2015 or active work 1872.2 and P2751) or the RIA (TR 15.606 or ANSI/RIA 15.06).

Many AMR companies have independent solutions. This diverse group set aside personal interests and agreed that co-existing in the same customer facility would better the future for all robotics companies and technology.

 There was initial discussion around sharing task information, showing availability and robot capability, and the need for a cohesive task allocation. This included debates around task allocation versus a high level of robot awareness of other robots in the vicinity. It was argued that AMR systems operating fleets may not need to share availability and capability of each robot outside of their network, but at a high level, there needs to be an understanding between the AMRs and potentially a way of communicating keep out areas and safe zones to operate. It was decided that “task management” would not be part of this initial interoperability standard and the group would start by focusing on basic robot to robot information sharing.

Ultimately, the group wants standard protocols for communications and information sharing that will be adopted by all, and future discussions were around what types of data needed to be shared.  The objective was to keep the standard simple so that each vendor could adopt it easily making the protocol adopted widely.

Feedback from the customers:
To understand the community and end user/customer need, the group met with solicited feedback from industry representatives including FedEx, Proctor and Gamble and DHL. The overall feedback supported the groups vision and future customers shared:

  • They are testing AMRs from multiple vendors and different systems.
  • They are looking for standards that can be used in an environment where both humans and robots/AMRs (from multiple vendors) can work together.
  • Not one provider can do all tasks necessary.

The customers confirmed that interoperability is needed and not one AMR vendor or type can solve all the needs. Each vehicle needs awareness of where others are so that routes can be optimized.

Overall, there must be a cohesive management operating system and AMR fleets need to interact and share awareness, operations and planning so that missions can be coordinated and integrated.

When asked how immediate the need is for interoperability the customer’s views varied from immediate to 18-24 months.

With these major shipping, manufacturing, and distribution customers validating the need and requirements for data sharing standards – the group decided to press on.

Where to start – keep it simple:
Discussion in the group continued around the full spectrum of interoperability with tasks and implementation put into high level buckets – beginning with the easiest to solve near term, to the more difficult and complicated:

  • Information Sharing, floor and fleet management (knowing where assets are on the floor)
  • Task management, task allocation – more complicated to receive instructions.
  • Hardware changes (example sharing chargers between various vendors)
  • Other types of automation solutions, expanding to arms and other solutions.

All agreed to tackle the easiest information sharing robot-to-robot first – get consensus and adoption, then move forward with potentially more difficult tasks.  The standard is not trying to make decisions and send instructions to robots, but to provide useful information needed to make those decisions.  Discussions that followed focused on the data, the methods to share, and the message format.

The Data:
Several discussions focused on what data would be useful to exchange and valuable for a customer who wants a wholistic view and all AMRs in their space. This group’s goal was not to create the dashboard or view, but to provide the information that one would need to create this view.

Several weeks of discussions focused on the following topics and data points to be shared and considered:  Common reference location, current location and future destination, manufacturer name, model, dimensions, AMR unique identifier (RFC 4122 standard), categories for data, a robot’s state (active vs idle and available vs not available), common reference location (GPS or reference points), defining future position and destination, frequency of messaging, timestamps, synchronous vs asynchronous messaging.

Methods of Messaging/Transport:
Many protocols and transport systems were discussed, including: Zero MQ, Websockets (RosBridge), DDS (ROS2), MQTT, AMQP, WebRTC, HTTP2, ROS1, UDP.

The group worked to narrow the playing field and investigated several. There was discussion around building a ROS opensource “bridge” to implement the services and receive messaging. ROS1 and UDP were eliminated and after participant votes: MQTT and Websockets were investigated further.

A ROS2 expert met with the group and shared a project they are working in the healthcare space with several vendor types.  Their developed protocol was not focused on Robot-to-Robot communications, but similar to a high-level coordinator (or referee) for traffic control. There was no robot to robot communication – their messages are passed between fleet managers with their focus on monitoring resources and shared spaces.

When comparing protocol transport messaging, the following items were taken into consideration: security, external agent requirements, firewall challenges, risk of dropped messages, bandwidth, resource consumption, ubiquity/universality of format, simplicity of adoption, robustness to loss of network, common language support. Pros and Cons for the various methods were discussed and the final choice was JSON over Websockets as the protocol that will be used in the initial standard (this can easily be updated to include additional methods in the future).

Message Format:
It was decided to group the data to be shared in two messages: (1) setup message and (2) status message (to include future destination).

Message descriptions and script tool can be found on our Git Hub repository that is public, searchable on the web, read only and can be found here:  https://github.com/MassRobotics-AMR/AMR_Interop_Standard

Future:
Participating company’s data can be provided via this standard to customers so they can populate their own dashboards.  The AMR Interoperability Working Group is seeking feedback so that these standard messages can be adopted and useful for all.

Members of the MassRobotics AMR Interoperability Working Group and contributors to publication of the standards include: Vecna Robotics, 6 River Systems, Waypoint Robotics, Locus Robotics, Seegrid, MiR, Autoguide Mobile Robots, Third Wave Automation, A3, and Open Robotics. Additionally, end users from major shipping and distribution centers have validated the need and requirements for such a standard. The first use case will be trialed at a FedEx facility where AMRs from Waypoint Robotics, Vecna Robotics and others will be operating in the same area.