The short answer
The MassRobotics AMR Interoperability Standard is a free, voluntary communication standard that lets autonomous mobile robots (AMRs) from different manufacturers tell each other who they are, where they are, how they are moving and where they are going next, so they can share a warehouse or factory floor. It defines just two JSON messages, an identity report and a status report, sent over WebSockets, plus a common way to put every vendor's robots on the same map. It does not give orders, assign tasks or deal with safety, which is covered by vehicle standards such as ISO 3691-4. Version 1.0 was published in 2021 by MassRobotics, a non-profit robotics innovation hub in Boston, after work by a group of AMR makers and end users.
At a glance
| Item | MassRobotics AMR Interoperability Standard |
|---|---|
| What it is | An information-sharing standard between mobile robots, or their fleet managers, from different vendors |
| Published by | MassRobotics AMR Interoperability Working Group (formed 2020), chaired by MassRobotics |
| Current version | 1.0, published 2021 |
| Messages | Identity report and status report |
| Transport and format | WebSockets (IETF RFC 6455) with JSON (ISO/IEC 21778:2017); JSON schema on GitHub |
| Status of use | Voluntary; the document says it may be revised or withdrawn at any time |
| Typical robots | AMRs and other industrial mobile robots in warehouses and factories |
The problem it solves
Many warehouses now run mobile robots from more than one maker: picking robots from one, pallet movers from another, tuggers from a third. Each fleet manager knows only its own machines, so robots from different fleets treat each other as unknown obstacles. They slow down, stop or reroute around machines they could have planned around. The working group's aim was a small, simple message set that every vendor could adopt quickly, so each fleet can see the others and plan with them in mind, while keeping its own navigation and safety.
Who is behind it
The MassRobotics AMR Interoperability Working Group was formed in 2020. The version 1.0 document was chaired by MassRobotics, with Vecna Robotics, 6 River Systems and Waypoint Robotics as voting members and Locus Robotics among non-voting members. MassRobotics also names Seegrid, MiR, Autoguide Mobile Robots, Third Wave Automation, the Association for Advancing Automation (A3) and Open Robotics as contributors, and says FedEx, DHL and Procter & Gamble gave end-user input. MassRobotics announced the published standard in May 2021, with a first trial planned at a FedEx facility.
The two messages
The standard defines what a robot, or the fleet manager speaking for it, shall, should and may send. A robot needs only the "shall" items to conform.
| Message | Required (shall) | Recommended or optional |
|---|---|---|
| Identity report | Unique ID (RFC 4122 UUID), UTC timestamp, manufacturer, model, serial number, robot footprint in metres | Should: maximum speed, maximum run time, emergency contact, charger type, support vendor and contact. May: documentation link, thumbnail image, cargo type, cargo volume and weight limits |
| Status report | The robot's UUID, UTC timestamp, operational state, location on the shared map | Error codes when something is wrong. Should: linear and angular velocity, up to ten upcoming work locations no more than 15 minutes ahead. May: battery percentage, remaining run time, a short path forecast for the next 10 seconds (up to ten points), load percentage used |
The operational state is one of nine values: navigating, idle, disabled, offline, charging, waiting for a human event, waiting for an external event, waiting for an internal event, or manual override. If no error codes are sent, the robot is assumed to be working normally; example codes include a sensor safety stop, a manual emergency stop, low battery, robot lost and robot stuck.
How often robots report
| Message | When it is sent |
|---|---|
| Identity report | At least at power-up or on request, and whenever any identity data changes |
| Status report | Whenever the status changes, never more than once a second, and at least every 30 to 60 seconds (the version 1.0 text gives both figures) |
One map for every vendor: the planar datum
Robots from different makers each build their own map, so a position like "x 12, y 40" means nothing to a robot from another fleet. The standard fixes this with a planar datum: a flat coordinate frame for each floor, with a level number (ground floor 0, basement −1). Each datum is tied to at least two, and preferably three or more, datum reference points, physical features such as support columns or fiducial markers measured in the site's coordinate system. The standard recommends, but does not require, latitude and longitude. Each vendor locates the same physical points in its own map and can then convert positions both ways. Two points allow rotation, translation and scaling; three points that are not in a line allow a full affine transformation. Reference points should be spread across the area the robots use to reduce measurement error.
What it does not cover
- No commands. It shares information for decision-making; it does not tell any robot what to do.
- No task management. The working group left task assignment out of the initial standard.
- No safety. The document says it must not be relied on for any safety purpose. Safety stays with each robot and with standards such as ANSI/RIA R15.08 and ISO work under TC 299.
- No shared hardware. Shared chargers and other physical interoperability were left for later phases, as were robot arms and other automation.
- Coordination is still up to the fleets. Knowing where another vendor's robot is going only helps if your fleet manager uses that information when planning.
MassRobotics, VDA 5050 and Open-RMF compared
| Standard | What it does | Transport | Best fit |
|---|---|---|---|
| MassRobotics | Robots or fleets from different vendors share identity, position, state and planned destinations; no orders | WebSockets, JSON | Several AMR fleets that each keep their own fleet manager |
| VDA 5050 | One master control sends transport orders to vehicles and receives their state | MQTT, JSON | AGVs, AMRs, tuggers and forklifts under one master control |
| Open-RMF | Open-source framework that schedules traffic between fleets, hands out tasks and connects doors and lifts | ROS 2 | Service, cleaning, delivery and security robots sharing a building |
The three are not rivals so much as different depths of integration. MassRobotics is the lightest: fleets stay independent and simply stop being blind to each other. VDA 5050 hands control of every vehicle to one master control. Open-RMF sits between fleets and the building. See robot fleet management across vendors for how one layer above them holds the shared map and rules.
Questions to ask a supplier
- Which messages, which fields? Ask whether the robot or its fleet manager sends both reports, and which "should" and "may" fields it fills, especially destinations and the 10-second path.
- Sender or receiver? Sending its own status is half the job. Ask whether the fleet manager also reads other vendors' status reports and uses them in its route planning.
- Datum reference points. Ask who surveys the reference points and aligns each vendor's map during commissioning.
- Other interfaces. Ask whether the machine also supports VDA 5050, an Open-RMF fleet adapter or a documented ROS 2 or REST interface, which allow control as well as visibility.
Where HORMĒ fits
HORMĒ is a Behavioral Intelligence platform for autonomous machines, based in Dubai, United Arab Emirates. Its behavior layer sits above the vendors' own systems and connects machines through VDA 5050, Open-RMF, ROS 2 or a connector written against the manufacturer's own interface, so machines from different vendors run as one fleet under one site model and one set of rules. The layer is licensed per machine per month: Core from $149, Autonomy from $349 and Assured from $690, indicative. See what Behavioral Intelligence is, pricing, and the machines this most often applies to: warehouse robots and autonomous forklifts and delivery and service robots.
Frequently asked questions
What is the MassRobotics AMR Interoperability Standard?
The MassRobotics AMR Interoperability Standard is a free, voluntary communication standard that lets autonomous mobile robots from different manufacturers share their identity, location, speed, direction, state and planned destinations, so they can work in the same warehouse or factory. Version 1.0 was published by MassRobotics, a Boston robotics innovation hub, in 2021.
Who wrote the MassRobotics interoperability standard?
It was written by the MassRobotics AMR Interoperability Working Group, formed in 2020 and chaired by MassRobotics. Robot makers Vecna Robotics, 6 River Systems and Waypoint Robotics were voting members, and MassRobotics names Locus Robotics, Seegrid, MiR, Autoguide, Third Wave Automation, A3 and Open Robotics among contributors, with input from FedEx, DHL and Procter & Gamble.
What messages does the MassRobotics standard define?
It defines two messages. The identity report describes the robot: a unique ID, manufacturer, model, serial number and footprint, plus optional details such as maximum speed and charger type. The status report gives the robot's operational state, location and timestamp, and optionally its velocity, battery, error codes, upcoming destinations and short-term path.
How do robots from different vendors share one map under the MassRobotics standard?
The site defines a planar datum, a flat coordinate frame for each floor, anchored by two or more datum reference points such as support columns or fiducials. Each vendor maps the same physical points in its own system, so positions can be converted between the robot's map and the shared frame.
How often must a robot send MassRobotics status messages?
A status report is sent whenever the robot's status changes, no more than once a second, with a minimum interval that the document gives as thirty to sixty seconds. The identity report is sent at least at power-up or on request, and whenever the identity data changes.
Does the MassRobotics standard control robots?
No. It shares information only. It does not send orders, assign tasks or address safety, and each robot remains responsible for its own navigation and safety. Task management was deliberately left out of the first version.
What is the difference between the MassRobotics standard and VDA 5050?
The MassRobotics standard lets robots from different vendors report who they are, where they are and where they are going, so their fleet systems can avoid each other. VDA 5050 is a command interface: one master control sends transport orders to AGVs, AMRs and forklifts over MQTT and receives their state. MassRobotics uses WebSockets and does not issue orders.
Check the current MassRobotics documents before relying on any detail. Sources: MassRobotics AMR Interoperability Standard on GitHub (version 1.0 document and JSON schema), MassRobotics announcement, May 2021, MassRobotics AMR interoperability project.
Ask about a mixed fleet