Mixed-robot compatibility
AMR Fleet Management Software: What Mixed-Robot Compatibility Really Requires
Read a mixed-robot software proposal at the level of the proposed robot, controller and required functions—not just the standards named on a product page.
This guide draws on public technical documentation and supplier statements. It is an editorial comparison, not a report of a tested installation. The worked example and diagrams are conceptual; support for a proposed configuration needs separate confirmation.
Evaluate AMR fleet management software against the exact robot–controller pairing you plan to use, including its software releases, command direction and required functions. Then check what the supplied evidence actually covers: a protocol definition, an implemented software component or that delivered pairing. A mixed-brand label alone does not answer both questions.
Compatibility belongs to a specific robot–controller pairing
Start by asking who is controlling whose robot. A supplier's fleet manager operating another manufacturer's robot is a different combination from that supplier's robot operating under another fleet manager. Both may be advertised as mixed-fleet compatibility, but evidence for one combination does not establish the other.
This distinction appears in real supplier wording. Ati's fleet-manager page separately advertises control of other vendors' robots and operation of its Sherpa AMRs under another fleet manager. Those are attributed supplier statements, not independently verified pairings. Use the distinction to make your own proposed control direction explicit.
The same caution applies when reviewing HiO. HiO's navigation and fleet technology describes the iMS platform and operation through compatible third-party fleet control. That overview does not identify a supported software release for your particular proposed pairing. Ask for the relevant combination to be confirmed rather than treating the overview as a version-specific support record.
Put versions and required functions beside the compatibility claim
For each proposed pairing, record the robot model and firmware, controller name and release, interface version, command direction, and functions your workflow requires. Keep these together: a document about the right manufacturer but a different controller release may not answer the question you are buying against. If a field is unknown, leave it visibly unconfirmed instead of completing it from a broad product label.
VDA5050 Version 3.0.0, dated March 2026, describes semantic versioning, including breaking major-version changes, and distinguishes mandatory from optional communication topics. For example, its topic table lists visualization as optional. Naming VDA5050 therefore does not, by itself, identify the version or every function included in a particular implementation.
Supplier qualifications are worth reading alongside the headline. The note on ANT server's fleet-manager page says VDA5050 vehicle integration involves additional programming time and cost. It also qualifies functionality relative to its native capabilities at the time of writing. That is a vendor-specific qualification, not a universal limitation of VDA5050 or a cost estimate for your project. The useful follow-up is which required functions the quoted scope includes and which still need implementation.
Work through one incomplete proposal
Consider a fictional proposal for Controller A and Robot B, with their releases identified in the proposal. Your planned workflow needs a travel command and a load-transfer action. The supplier provides pairing-specific evidence for the travel command, but the only material supplied for load transfer is a general statement naming a supported standard.
Fictional procurement comparison—not supplier test data
| Question being checked | Evidence supplied in this example | What you can conclude |
|---|---|---|
| Controller A issues the named travel command to Robot B | A pair-specific record | The record supports only the named command and configuration. |
| The same pairing performs the required load-transfer action | A generic supported-standard statement | The required function remains unconfirmed. |
| Controller B operates Robot A | No record for this combination | This is a separate pairing, not established by the travel example. |
The useful result is a narrower unanswered question, not an automatic rejection of the supplier. Ask for evidence covering load transfer in the proposed configuration, or a clearly identified implementation scope if it is not yet supported. Do not turn one evidenced function into proof of the whole workflow. Likewise, an absent record means the claim is unconfirmed; it does not prove that the supplier cannot provide it.
Separate a protocol, a software component and a delivered system
Once the pairing is clear, inspect the kind of evidence attached to it. A protocol document explains communication rules. An implementation package performs a software role. Evidence about a delivered configuration concerns named components used together. These are related, but they answer different questions; citing one is not enough to establish the next.
A historical example makes the distinction tangible. In its October 19, 2022 explanation of Mission Dispatch and Client, NVIDIA describes Mission Dispatch as a microservice that can be integrated into a fleet-management system, and Mission Client as a robot-side ROS2/Nav2 package. The article is useful for understanding component roles. It is not evidence of current package support, a delivered HiO architecture, or compatibility with the exact robot and controller in your proposal.
Identify what the evidence leaves to another component or supplier
When a proposal names an open-source package, ask which role it performs, which release is included, and who supplies the surrounding integration. When it cites a protocol, ask which implementation and pairing the citation is meant to support. This separates useful documentation from a claim it was never intended to prove, without assuming that open-source or proprietary software is inherently more complete.
Keep the standard's own boundaries in view. The scope of VDA5050 Version 3.0.0 excludes safety requirements, traffic-management algorithms and project acceptance procedures. Its communication specification should not be presented as proof that those parts of a proposed system have been supplied or validated. This is a scope distinction, not a safety assessment of any particular installation.
For the fictional Controller A proposal, a software-package link could explain how one component is implemented without resolving the missing load-transfer evidence. Record the package's stated role and release, its supplier, and the integration work left open. Then return to the original requirement: what supports the required action for Controller A and Robot B? This keeps the purchasing decision tied to the proposed configuration rather than to the number of standards or project names listed in the response.
Take the unresolved pairing to the engineering discussion
Prepare a short brief with the robot model and firmware, controller release, required command direction and functions, plus the evidence already supplied. Mark what remains unknown and ask whether each gap is an existing supported capability, proposed integration work or outside the offered scope. This gives the supplier a specific question to answer without assuming that all requested combinations are available.
For the wider system connections and pilot process, continue with the AMR integration guide. Its broader project questions come after narrowing what the compatibility claim actually covers; they are not replaced by this comparison.
Sources and limitations
- VDA5050 Version 3.0.0: introduction, scope and communication-topic table. The discussion is not a complete conformance audit.
- Ati Fleet Manager: supplier statements about two control directions, not independent compatibility testing.
- ANT server: supplier-specific integration and functionality qualifications, including its at-time-of-writing limitation.
- NVIDIA Mission Dispatch and Client article: historical component explanation published in 2022, not a current release or support audit.
No specific HiO pairing, optional function or protocol version is confirmed by this guide. Request project-specific support evidence before relying on a proposed combination.
Discuss your proposed configuration
Bring the named robot and controller releases, required functions and unresolved evidence to an engineering enquiry. Ask HiO to confirm the offered scope for that combination; the enquiry itself is not a compatibility guarantee.