FleetMeshInformation sharing, not a fleet controller
The MassRobotics AMR Interoperability Standard describes a common exchange of robot information. Identity and operational reports can help other systems understand which robots are present and what they are doing. The standard does not itself implement a central traffic manager, dispatch work, or supply a complete task-orchestration engine.
Source: official repository overview and MassRobotics scope explanation.
Document boundary
This guide uses the repository's v1.0 PDF and source snapshot f9357a423ecabc3f7112e6d10025a5231943ec50, checked 8 October 2026. The commit is an immutable repository snapshot, not a claim that every file has a shared release tag. This guide is independent commentary, not certification.
Identity and status reports
The published JSON schema describes two report structures. Keep stable identity separate from changing operational state, and associate reports with their robot UUID.
| Report | Representative fields | Engineering use |
|---|---|---|
| identityReport | uuid, timestamp, manufacturerName, robotModel, robotSerialNumber, baseRobotEnvelope | Identify the machine and interpret its physical footprint. Optional capability fields need explicit support decisions. |
| statusReport | uuid, timestamp, operationalState, location | Associate a time-stamped operational observation with a known robot. Optional fields add context rather than command authority. |
Source: schema definitions and required properties. Engineering-use interpretations are FleetMesh commentary.
Location, velocity and direction
The location structure carries coordinates and an orientation quaternion; planarDatum identifies the reference context. Velocity can describe linear speed and direction, with angular information represented separately. A location report is not meaningful to another fleet until both sides agree how its reference frame maps to the shared space.
Do not equate reported destinations or a path with exclusive occupancy rights. A consumer may use these observations in its own coordination system, but receiving a path does not grant permission to enter an aisle or establish that another robot will stop.
Sources: location, velocity, destinations and path definitions and v1.0 PDF, data model. The occupancy distinction is FleetMesh integration guidance.
Health, availability and task context
Use the schema's actual fields instead of inventing a generic health or task object. operationalState distinguishes states such as navigating, idle, disabled, offline, charging and waiting conditions. errorCodes adds reported error information; batteryPercentage and remainingRunTime provide energy context when present.
loadPercentageStillAvailable concerns remaining load capacity. It is not a universal boolean for readiness to accept work. destinations and path can expose intended motion or task-related context, but neither is a general-purpose task-assignment API.
Source: statusReport and operationalState definitions. Availability interpretation is FleetMesh guidance.
WebSockets, JSON and reference code
The v1.0 document specifies JSON messages over WebSockets. The official repository includes a Python sender example, a receiver example, and example messages. These are useful for examining the exchange, not a production deployment guarantee.
Source: v1.0 PDF, section 6 and the linked reference implementations.
The schema snapshot does not declare a $schema dialect. Do not assume it is Draft 2020-12 because the VDA schemas are. The published examples are illustrative artifacts, not evidence that every example satisfies every constraint: for instance, the UUID pattern uses lowercase hexadecimal while example identifiers include uppercase characters. Resolve such differences explicitly before using examples as test fixtures.
Compare the UUID pattern with identityReport1.json. FleetMesh's Message Explorer currently validates VDA 5050 only.
Questions to settle before integration
- Which system owns identity, coordinate transforms and map changes?
- Which optional fields does each producer actually send, and how does a consumer represent unknown or missing values?
- How are stale, delayed or disconnected reports represented without confusing silence with availability?
- Who issues tasks, reserves shared resources and resolves conflicting intentions?
- How are access control, transport security, monitoring and failure recovery implemented?
- Which physical safety measures remain independent of the information-sharing channel?
FleetMesh engineering checklist, not additional normative requirements. Reporting robot state is not a safety-rated interlock.
Source record
Repository snapshot: f9357a423ecabc3f7112e6d10025a5231943ec50. The PDF, schema, examples and sender/receiver remain the primary materials. Record document versions and investigate inconsistencies before implementation.