Robot Dog ↔ AGV/AMR Coordinated Dispatch System Software · Comparative Reference List — Who Else Besides SEER Is Worth Studying (Open-Source Frameworks openTCS / Open-RMF × VDA5050 Standard × Commercial Benchmarks × Domestic RCS × Single-Robot Navigation Nav2 · All External Links curl-Verified)

⚠️ Working draft under continuous verification — a self-development reference. Strategic premise (decided by the boss on 2026-06-29): the coordinated work system software for robot dogs and AGV/AMR will be developed in-house by the company, with SEER being only one reference benchmark. This piece sweeps across what other "robot dog ↔ AGV/AMR coordination / multi-robot dispatch / fleet management" system software exists at home and abroad — besides SEER — that can serve as a self-development reference, giving each one an entry on "architecture / external interfaces / open-source or not / can it be borrowed / can quadrupeds be included." All external links are curl-tested: government sites returning 000 = geo-blocking, commercial/news sites returning 403 = browser UA required, all treated as valid official pages, not dead links; any interface/license details that are uncertain are marked UNVERIFIED, not fabricated. Companion sister piece: SEER framework breakdown · self-development reference.

🧭 One-Sentence Overview

After the full sweep, the two things genuinely usable as a "self-development kernel blueprint" are two open-source frameworks — openTCS and Open-RMF; VDA5050 is a communication standard worth benchmarking against (but it targets only 2D wheeled robots); commercial systems like OTTO / MiR / Spot Orbit / ANYmal are closed-source at their core, so only their architecture and external-interface paradigms can be borrowed; domestic warehousing RCS (HAI Robotics/Quicktron/Geek+/ForwardX/Hikrobot/Enotek) are generally closed-source, basically only dispatch their own vehicles, and don't support quadrupeds; Unitree and DEEP Robotics only provide single-robot SDKs, with no off-the-shelf fleet software — which precisely confirms that the "robot dog × AGV/AMR heterogeneous coordinated dispatch layer" is a real market gap, and the differentiation space for self-development. Single-robot navigation needs no reinventing — just use Nav2.

🔍 Open-Source Frameworks (the most direct references for self-development)

openTCS (Fraunhofer IML, MIT) — blueprint for the self-developed dispatch kernel

A fleet-level dispatch and control platform open-sourced by Germany's Fraunhofer Institute for Material Flow and Logistics, controlling AGV/AMR fleets and providing "an abstract driving model + transport order management + path computation"¹.

Three-piece architecture: Kernel — the central control process that maintains the plant model, manages transport orders, and computes paths; Plant Overview — the graphical frontend, split in newer versions into Model Editor (modeling) and Operations Desk (operation); Kernel Control Center — manages/monitors the kernel, attaching and configuring vehicle communication adapters¹.
Three-piece pluggable strategies: Dispatcher (task dispatch) / Router (routing) / Scheduler (resource mutual-exclusion) are all replaceable — these are exactly the three layers of capability the self-developed coordination core needs to build.
Vehicle driver mechanism: one communication adapter per vehicle type, translating between the abstract kernel interface and the vehicle's proprietary protocol; ships a loopback adapter for hardware-free simulation.
External interfaces: ① a Java RMI service API; ② an HTTP/JSON Web API (REST-style — create/cancel transport orders, query vehicle/order status, X-Api-Access-Key authentication, with an OpenAPI specification file); ③ events /events (long polling) + newer /sse (Server-Sent Events)¹.
Open-source + license: fully open-source, current source code under MIT (docs CC-BY-4.0); whether it once used LGPL/GPL early on is UNVERIFIED, but the current MIT is verified.
VDA5050: an official built-in adapter opentcs-commadapter-vda5050 (implements VDA5050 1.1/2.0, JSON over MQTT, MIT)²— proving that "southbound to AGVs via VDA5050" is a mature industrial route.
Can quadrupeds be included: theoretically yes — a vehicle is abstracted as "a transport entity moving on a Point/Path/Location topology graph," making no assumptions about wheeled vs. legged; you'd need to write a comm adapter for the robot dog + model the reachable space as a point topology. Limitation: the model is essentially "point-to-point transport on a graph," and a robot dog's free-terrain inspection, obstacle-crossing/stair-climbing and other continuous-motion semantics are hard to fully fit into a discrete topology.
What to borrow: pluggable communication adapters (the key to heterogeneous hardware decoupling — be sure to pair with loopback simulation) + Dispatcher/Router/Scheduler strategy abstraction + model-driven design (modeling/operation separation) + a layered external-interface template (internal RMI + external REST + event stream + OpenAPI + API Key).

Open-RMF (Open Robotics, Apache-2.0, built on ROS 2) — the most direct template for heterogeneous coordination

A set of reusable libraries and tools built on ROS 2, implementing "interoperability of heterogeneous, multi-vendor, multi-type robot fleets" and bringing building infrastructure (doors, elevators, dispensers) into the coordination as well; its motto is "A Common Language for Robot Interoperability," and it has been maintained by OSRA since 2024³.

Layered architecture: RMF Core — rmf_traffic (traffic management: a globally shared reservation-based schedule + conflict prediction + multi-fleet negotiation for de-conflicting), rmf_task (task allocation), rmf_battery (battery modeling); the Fleet Adapter layer (one adapter per fleet/vendor to integrate); the infrastructure integration layer (door/lift/dispenser adapters); rmf-web (browser dashboard + REST/HTTP API server, default port 8000, with Swagger/OpenAPI)⁴.
Fleet Adapter three-tier integration (the most valuable design pattern, and mixable within one deployment)⁵:
- Full Control: RMF can assign/interrupt paths and de-conflict in real time (there's an EasyFullControl simplified version);
- Traffic Light: RMF can only pause/resume (EasyTrafficLight);
- Read-Only: the fleet only reports FleetState, and RMF merely predicts and avoids;
- Mixed: the above levels coexist under unified planning.
External interfaces: the rmf-web REST API server (including /docs Swagger, a trajectory WebSocket, and an HTTP task API); the underlying components run over ROS 2 topics/services.
Open-source + license: fully open-source, Apache-2.0 (no copyleft contagion — code and design can be borrowed directly).
Heterogeneity: the core selling point is exactly multi-fleet/multi-vendor; awesome_adapters lists about 18 Full Control adapters (MiR, Gaussian, Temi, TurtleBot, Clearpath, LionsBot, etc.)⁷; it has a bridgeable relationship with VDA5050 (the community has an experimental VDA5050 fleet adapter — not the official core, so maturity must be self-assessed).
Can quadrupeds be included: Yes, and this is RMF's key advantage over openTCS/VDA5050 — RMF abstracts "any navigable mobile robot," and a robot dog joins as a fleet via a custom adapter (can accept/replace paths and report pose in real time → Full Control; can only pause/resume → Traffic Light; in early stages just wants to be seen and avoided → Read-Only), and can be dispatched in a shared pool with wheeled AMRs + third-party vehicles, sharing the traffic schedule and the same doors/elevators.
What to borrow: the Fleet Adapter abstraction + three-tier integration (progressive rollout by integrator capability) + centralized traffic management and resource negotiation + the task allocation/battery modeling framework + door/elevator/dispenser infrastructure abstraction. See the template at fleet_adapter_template ⁶.

📊 Communication Standard: VDA5050

A German VDA/VDMA standard (now v3.0.0, developed by VDA + VDMA + KIT) that lets AGV/AMR from any vendor communicate with the same master control using unified messages — abstracting "task dispatch / status reporting" into a vendor-neutral message contract⁸.

Protocol essence: MQTT (≥3.1.1) + JSON; topic structure interfaceName/majorVersion/manufacturer/serialNumber/topic; six topics: order (master→vehicle, with a node/edge road network), state (vehicle→master), connection (last-will online detection), instantActions (an immediate-command bypass), factsheet (vehicle capability self-description), visualization (high-frequency pose); the navigation model = a node/edge directed graph + base/horizon progressive release; pose is only x,y,theta,mapId (2D plane + heading)⁹.
License (dual-track — must distinguish for adoption): the GitHub repo is marked MIT (for assets like the schema), but the specification text is under VDA copyright (may be copied only with attribution).
Open-source implementations (verified one by one): libVDA5050++ (a middleware library for both the vehicle and master sides, C++, main repo under cmraaron, led by Fraunhofer IML)¹⁰; InOrbit/Ekumen connector (a vehicle-side ROS2↔VDA5050 bridge, BSD-3)¹¹; berketunckal/VDA5050-FleetManagement (an open-source master/fleet-side reference, Python+PostgreSQL)¹²; NVIDIA Isaac Mission Dispatch (a VDA5050-compatible cloud task dispatch)¹³. Meili FMS is not open-source (paid license) and doesn't count as an open-source reference.
Quadrupeds: explicitly targets 2D wheeled robots — no gait/roll-pitch/obstacle-crossing/3D-posture/foot-end fields, and the road-network assumption is unsuitable for unstructured terrain → quadrupeds should borrow VDA5050 as a semantic skeleton (order/state/factsheet/instantAction), not as a direct target protocol.
What to borrow: the standardized order/state message model (vendor-neutral, versioned, with wheeled/quadruped sharing the semantic skeleton and each extending its own fields) + MQTT decoupling + connection last-will disconnection detection + factsheet capability self-description (quadrupeds can add gait/obstacle-crossing/posture capability slots) + the instantAction bypass channel (quadruped emergency-stop/posture-switch) + the base/horizon progressive-release idea for right-of-way allocation.

🏭 Commercial Fleet Management / Robot Operations Systems (closed-source benchmarks)

Closed-source at their core — borrow the architecture and external-interface paradigms, not the code.

OTTO Motors / Rockwell Automation (OTTO Fleet Manager): acquired by Rockwell in 2023; does traffic management, task dispatch, and fleet visualization. The core Fleet Manager is closed-source, but they open-sourced a VDA5050 connector; OTTO's entire AMR line is already VDA5050-certified and can be managed by third-party master controls¹⁴. Quadrupeds: 2D wheeled only. Borrow: the three-layer decoupling "business system → fleet management → vehicle (VDA5050+MQTT)" + the open-source connector as reference code for a VDA5050 bridge. (Note: the official wording "REST" is not stated verbatim, marked UNVERIFIED.)
MiR Fleet (under Teradyne, acquired 2018): event-driven architecture, officially claimed to support 100+ AMRs; provides a complete REST API (for ERP/MES/WMS), and the API documentation embeds the product UI for direct trial calls; closed-source, but the VDA5050 Adapter (a REST→MQTT translation layer) is open-source¹⁵. Quadrupeds: 2D wheeled only. Borrow: the "internal REST + bolt-on VDA5050 adapter" decoupling pattern — perfectly suited to "internal proprietary protocol, external VDA5050 for heterogeneous (including robot dog) integration." (Errata: MiR belongs to Teradyne, not Zebra; Zebra acquired Fetch, which it later spun off to Skild.)
Boston Dynamics Spot Orbit (formerly Scout) — quadruped operations benchmark: site-level fleet management software for the Spot quadruped robot dog, doing task scheduling, inspection-data archiving, anomaly detection, automatic docking, and condition-triggered actions; three deployment forms (Cloud / on-premise Site Hub 1U / VM-OVA). External interfaces (verified verbatim): ✅ official REST API (/api/v0/ prefix) + Webhooks (HMAC-SHA256 signature in the Orbit-Signature header) + Bearer Token¹⁶; the software core is closed-source, while the Spot SDK (including Orbit API examples) is BSD open-source on GitHub. Manages only Spot, no VDA5050. Borrow: REST + Webhook (HMAC-SHA256) + Token is the gold template for a self-developed external interface; "site + task scheduling + inspection archiving + anomaly detection + automatic docking + work-order integration" can directly serve as a feature blueprint for the robot-dog side.
ANYbotics ANYmal — quadruped-native: an industrial inspection quadruped + fleet management suite, with edge-collected device-health data encrypted and uploaded, plus the in-development Workforce Suite (a three-role permission model); external RESTful API (endpoint/auth details not public, marked UNVERIFIED), with documentation actually hosted on the Siemens developer portal; closed-source, integrating with asset-management/digital-twin systems like Cognite/Yokogawa¹⁷. Manages only its own, no VDA5050. Borrow: the "edge collection → encryption → API upload to asset management/digital twin" data-productization route + role-layered permissions. (Note: no standalone "D-suite" product was found; the naming is UNVERIFIED.)
DEEP Robotics (Jueying): quadruped-native, with Jueying Lite3/X20/X30 aimed at power inspection, substations, cable tunnels, and emergency response; GitHub has a single-robot SDK (robotserver_sdk, MIT, explicitly "to control and monitor a single dog's navigation tasks," XML/JSON over TCP)²¹. No public general fleet/multi-robot dispatch API was found (UNVERIFIED). The value to borrow lies in scenario definition; the software/API is not an interface benchmark — which again confirms that domestic quadrupeds lack unified open fleet software.
Unitree: no official unified fleet/dispatch software — only a per-robot SDK (unitree_sdk2, C++/Python, low-level CycloneDDS, ROS2-compatible); multi-robot coordination must be self-built²⁰. (Debunked: the rumored "Unitree fleet platform" is marketing copy from a third-party customization vendor, not official; eai.unitree.com is a data/training platform, not a dispatcher.) Borrow: it confirms that "only a single-robot SDK, no fleet software" is the norm — self-developed coordination/dispatch software is a real gap; choosing Unitree as a fleet member requires a custom adapter wrapping its DDS SDK.

🇨🇳 Domestic Warehousing RCS / WCS (closed-source; borrow architectural ideas, not code)

Generally closed-source commercial, with non-public APIs, basically only dispatching their own vehicles, and no quadruped support; the order pool / task allocation / traffic control / WMS decoupling interface design can be borrowed.

HAI Robotics (HAIQ): the dispatch core HAIQ, comprising WES (business execution) + ESS (equipment scheduling RCS) + data/simulation/algorithm platforms, which can run standalone or embed into an existing WMS; the ESS standard task interface = dispatch/cancel/modify/status-feedback; dispatches only its own ACR/AMR²². Borrow: decoupling of the business-execution layer ↔ equipment-scheduling layer + a standard task interface contract.
Quicktron (RCS): the RCS positions itself as the "fleet's central nervous system," decoupled from upstream WMS/ERP/MES/MIS/OMS/TMS, focused on hundreds-of-units-scale traffic-flow optimization and deadlock-avoidance²³. Borrow: the boundary of a pure RCS decoupled from WMS (the closest fit for the "self-develop only the coordinated dispatch" route) + an upstream-agnostic generic task model.
Geek+ (RMS) — the domestic offering closest to "heterogeneous same-pool": three-layer decoupling of RMS (dispatch) + WES (execution) + IOP (operations); the RMS explicitly supports a dual track of VDA5050 + Geek+'s own protocol, can integrate partners' third-party robots, and does homogeneous/heterogeneous mixed dispatch (>5000 units per site), provides an open API + SDK, and unifies the dispatch of multiple of its own robot forms via robot-modeling capability²⁴. Borrow: three-layer decoupling + the VDA5050 dual track + robot modeling (the key abstraction for bringing quadrupeds in as a new vehicle type for heterogeneous dispatch).
ForwardX (f(x)): vision-SLAM markerless navigation (no QR codes/reflectors needed) + cluster dispatch + human-robot collaborative picking, with an API for upward integration with WMS/MES/ERP²⁵. Borrow: QR-code/magnetic-strip-free navigation + human-robot collaborative task allocation + an API design decoupled from upper-level systems.
Hikrobot (RCS-2000) — the most standardized domestic offering: RCS-2000 (V4.0) + RCS-Lite, multi-vehicle-type mixed dispatch, a secondary-development four-piece set (including the heterogeneous-integration low-code platform iDataBus), and it led the national standard GB/T 43047-2023 "Technical Specification for Logistics Robot Control System Interfaces" (published, full text available)²⁷. Borrow: the interface-standardization route + low-code business orchestration; the southbound interface can align with both VDA5050 and the national standard GB/T 43047.
Enotek (formerly Eoslift): WMS/WCS + AGV dispatch (ADS), integrating via DBLink/webservice/TCP-IP/OPC; closed-source, only its own vehicles, no quadruped support²⁸. Borrow: WMS ↔ dispatch decoupling + a multi-protocol integration matrix. (Note: the commonly searched ant-robots Ant dispatch is a different company, unrelated to Enotek.)
VDA5050 domestic localization: the industry follows a "national standard GB/T 43047 + group standards from the likes of SIASUN" route to push its own interface standardization; apart from Geek+'s explicit stance, no other vendor's official site clearly states "commercial support for VDA5050 + heterogeneous third-party vehicles," marked UNVERIFIED, taken only as a trend.

ROS 2 Nav2 (Navigation2) — the single-robot navigation layer, don't reinvent it: a single-robot autonomous navigation stack (below the fleet adapter), a behavior-tree-orchestrated collection of servers (BT Navigator / Planner / Controller / Costmap / Recovery / Smoother / AMCL); externally primarily a ROS 2 Action (NavigateToPose, etc.) + fully plugin-based; mainly Apache-2.0 (a few packages BSD/LGPL, check package by package); officially supports legged chassis³⁰, but Nav2 only outputs the cmd_vel abstraction, and quadruped gait kinematics must be handled by the vendor's motion stack. Conclusion to borrow: use Nav2 directly for single-robot navigation, and let the coordination layer handle only dispatch (issue goals, subscribe to state, and leave traffic/dispatch/avoidance to the self-developed coordination layer)²⁹.
The Fleet Adapter design pattern: "one adapter per vendor/per fleet (an anti-corruption layer)" — the dispatch kernel is vendor-neutral, and adding a new machine = adding a new adapter with zero core changes. Self-development should directly copy the "vendor-neutral dispatch kernel + one adapter per machine class" layering: write a Nav2-action adapter for the robot dog, write a VDA5050 adapter for external AGVs, and never hard-code a brand's proprietary protocol into the dispatch logic.
WCS / WES / RCS / FMS / WMS boundaries: WMS = business/inventory (minutes to hours); WES = execution orchestration (seconds to minutes); WCS = coordination of fixed automation equipment (milliseconds); RCS/FMS = mobile-robot fleet dispatch (seconds to milliseconds). Self-development positioning conclusion: coordinated dispatch is explicitly placed at the RCS/FMS layer (heterogeneous task dispatch for dogs + AGV/AMR + traffic control + avoidance + charging + monitoring), integrating upward with the customer's existing WMS/MES via standard interfaces (without redoing inventory/orders) and connecting downward to all machine types via fleet adapters (including a VDA5050 client), with single-robot navigation on Nav2.
WCS/WES giants' boundaries (corroborating evidence): Dematic (KION) iQ fuses WMS/WES/WCS, with mobile-robot dispatch externally attached via RCS/FMS³¹; Siemens SIMOVE Fleetmanager explicitly manages heterogeneous fleets (different brands uniformly managed via protocols like VDA5050)³². The common thread: the giants don't rewrite each machine's navigation/motion control, but focus on WMS/WES/WCS, hand fleet dispatch to RCS/FMS, and integrate heterogeneous machines uniformly via VDA5050 — again proving the RCS/FMS layer is an open gap.

🎯 Summary Architecture Recommendations for Self-Development

Layered blueprint: business (WMS/MES) → self-developed coordination kernel (RCS/FMS: task dispatch + traffic control + avoidance + charging + monitoring) → Fleet Adapter (one per machine class) → single-robot navigation (Nav2) → vendor motion stack/gait control.
Core design patterns: copy Open-RMF's Fleet Adapter + three-tier integration (Full / Traffic-Light / Read-Only); copy openTCS's Dispatcher/Router/Scheduler strategy abstraction + model-driven design + communication adapter + loopback simulation.
External interfaces: copy Spot Orbit's REST + Webhook (HMAC-SHA256) + Bearer Token; openTCS's OpenAPI + API Key can serve as a template.
Southbound protocols: for external AGV/AMR, prefer VDA5050 (reference the REST↔MQTT translation layer of OTTO/MiR's open-source connectors, which can bridge into Open-RMF); since VDA5050 leans toward 2D wheeled robots, robot dogs should use a custom adapter (borrowing VDA5050's order/state/factsheet/instantAction semantics, extending gait/posture/obstacle-crossing fields).
Market-gap confirmation: Unitree only has an SDK, DEEP Robotics has no public general API, and domestic RCS all dispatch only their own vehicles — the "robot dog × AGV/AMR heterogeneous coordinated dispatch layer" is a real differentiation space.

⚠️ Honest Caveats and Errata (note before writing/facing customers)

openTCS's current license = MIT, verified; whether it was LGPL/GPL early on = UNVERIFIED.
libVDA5050++'s main repo is under cmraaron, led by Fraunhofer IML; Meili FMS is not open-source, and the genuinely open-source master-control reference is berketunckal/VDA5050-FleetManagement.
VDA5050's dual-track license: the repo is MIT (schema), the specification text is under VDA copyright.
MiR belongs to Teradyne (not Zebra; Zebra acquired Fetch).
OTTO's "REST" wording, ANYmal's endpoint-level details, DEEP Robotics' general API, and most domestic vendors' commercial VDA5050 support are all UNVERIFIED (vendors don't disclose), not fabricated.
Open-RMF's VDA5050 fleet adapter is community-experimental, not the official core; maturity must be self-assessed.