机器狗 ↔ AGV/AMR 协同调度系统软件·横向参考清单——除仙工外还有谁可借鉴（开源框架 openTCS / Open-RMF × VDA5050 标准 × 商用标杆 × 国产 RCS × 单机导航 Nav2·全外链 curl 验证）

⚠️ 持续核实中的自研参考草案。 战略前提（老板 2026-06-29 拍板）：机器狗与 AGV/AMR 的协同工作系统软件由公司自研，仙工 SEER 只是参考标杆之一。本篇横扫仙工之外、国内外还有哪些「机器狗 ↔ AGV/AMR 协同 / 多机调度 / 车队管理」系统软件可作自研参照，逐家给「架构 / 对外接口 / 是否开源 / 能否借鉴 / 四足能否纳入」。所有外链均 curl 实测：政府站 000=地域封锁、商业/新闻站 403=需浏览器 UA，均按有效官方页处理、非死链；拿不准的接口/许可细节一律标 UNVERIFIED，不编造。配套姊妹篇：仙工 SEER 框架拆解·自研参考。

🧭 一句话总览

横扫下来，真正能拿来当「自研内核蓝本」的是两个开源框架——openTCS 与 Open-RMF；VDA5050 是值得对标的通信标准（但只面向 2D 轮式）；OTTO / MiR / Spot Orbit / ANYmal 等商用系统本体闭源、只能借鉴架构与对外接口范式；国产仓储 RCS（海柔/快仓/极智嘉/灵动/海康/安歌）普遍闭源、基本只调自家车、不支持四足；宇树与云深处只给单机 SDK、没有成品车队软件——这恰恰印证「机器狗 × AGV/AMR 异构协同调度层」是真实的市场空白，也是自研的差异化空间。单机导航不用重造，直接用 Nav2。

🔍 开源框架（自研最直接的参考）

openTCS（Fraunhofer IML，MIT）— 自研调度内核蓝本

德国弗劳恩霍夫物流研究院开源的车队级调度与控制平台，控制 AGV/AMR 车队，提供「抽象行驶模型 + 运输订单管理 + 路径计算」¹。

架构三件套：Kernel（内核）——中央控制进程，维护工厂模型、管理运输订单、计算路径；Plant Overview——图形前端，新版拆为 Model Editor（建模） 与 Operations Desk（运行）；Kernel Control Center——管理/监控内核、挂载与配置车辆通信适配器¹。
可插拔策略三件套：Dispatcher（派单）/ Router（寻路）/ Scheduler（资源互斥） 均可替换——这正是自研协同核心要建的三层能力。
车辆驱动机制：每种车型一个 communication adapter（通信适配器），在抽象内核接口与车辆专有协议间翻译；自带 loopback adapter 用于无硬件仿真。
对外接口：① Java RMI 服务 API；② HTTP/JSON Web API（REST 风格，创建/撤销运输订单、查询车辆/订单状态，X-Api-Access-Key 鉴权，有 OpenAPI 规范文件）；③ 事件 /events（长轮询）+ 新版 /sse（Server-Sent Events）¹。
开源 + 许可：完全开源，现行源代码 MIT（文档 CC-BY-4.0）；早期是否曾用 LGPL/GPL 属 UNVERIFIED，但现行 MIT 已核实。
VDA5050：官方自带适配器 opentcs-commadapter-vda5050（实现 VDA5050 1.1/2.0、JSON over MQTT、MIT）²——证明「南向走 VDA5050 接 AGV」是成熟工业路线。
四足能否纳入：理论可行——车辆被抽象成「在 Point/Path/Location 拓扑图上移动的运输体」，对轮式/足式无假设；需为机器狗写 comm adapter + 把可达空间建成点位拓扑。局限：模型本质是「图上点到点运输」，机器狗的自由地形巡检、越障/上下楼等连续运动语义难完整套入离散拓扑。
借鉴什么：可插拔通信适配器（异构硬解耦的关键，务必配 loopback 仿真）+ Dispatcher/Router/Scheduler 策略抽象 + 模型驱动（建模/运行分离）+ 对外接口分层模板（内部 RMI + 对外 REST + 事件流 + OpenAPI + API Key）。

Open-RMF（Open Robotics，Apache-2.0，建在 ROS 2）— 异构协同最直接范本

建在 ROS 2 之上的可复用库与工具集，实现「异构多厂商、多类型机器人车队的互操作」，并把楼宇基础设施（门、电梯、料站）一并纳入协同；口号 "A Common Language for Robot Interoperability"，2024 年起由 OSRA 维护³。

分层架构：RMF Core——rmf_traffic（交通管理：全局共享预约式 schedule + 冲突预测 + 多车队 negotiation 去冲突）、rmf_task（任务分配）、rmf_battery（电量建模）；Fleet Adapter 层（每个车队/厂商一个适配器接入）；基础设施集成层（door/lift/dispenser 适配器）；rmf-web（浏览器 dashboard + REST/HTTP API server，默认 8000，带 Swagger/OpenAPI）⁴。
Fleet Adapter 三级集成（最值钱的设计模式，且支持同一部署内混合）⁵：
- Full Control：RMF 可指定/打断路径、实时去冲突（有 EasyFullControl 简化版）；
- Traffic Light：RMF 只能暂停/恢复（EasyTrafficLight）；
- Read-Only：车队只上报 FleetState，RMF 仅预测并避让；
- Mixed：上述等级共存、统一规划。
对外接口：rmf-web REST API server（含 /docs Swagger、轨迹 WebSocket、task API HTTP）；底层组件走 ROS 2 topics/services。
开源 + 许可：完全开源，Apache-2.0（无 copyleft 传染，可直接借鉴代码与设计）。
异构：核心卖点即 multi-fleet/multi-vendor，awesome_adapters 列出约 18 个 Full Control 适配器（MiR、Gaussian、Temi、TurtleBot、Clearpath、LionsBot 等）⁷；与 VDA5050 是可桥接关系（社区有实验性 VDA5050 fleet adapter，非官方核心、成熟度需自评）。
四足能否纳入：可行，且是 RMF 相对 openTCS/VDA5050 的关键优势——RMF 抽象「任意能导航的移动机器人」，机器狗作为一个 fleet 经自研 adapter 接入（能接受/替换路径并实时报位姿→Full Control；只能暂停/恢复→Traffic Light；早期只想被看见避让→Read-Only），可与轮式 AMR + 第三方车共池调度、共享交通日程、共用门梯。
借鉴什么：Fleet Adapter 抽象 + 三级集成（按接入方能力渐进式落地）+ 集中式交通管理与资源协商 + 任务分配/电量建模框架 + 门/电梯/料站基础设施抽象。模板见 fleet_adapter_template⁶。

📊 通信标准：VDA5050

德国 VDA/VDMA 标准（现 v3.0.0，VDA + VDMA + KIT 制定），让任意厂商 AGV/AMR 与同一主控用统一报文通信——把「派单/上报状态」抽象成厂商无关消息契约⁸。

协议本质：MQTT（≥3.1.1）+ JSON；topic 结构 interfaceName/majorVersion/manufacturer/serialNumber/topic；六个 topic：order（主控→车，含 node/edge 路网）、state（车→主控）、connection（last-will 在线检测）、instantActions（即时命令旁路）、factsheet（车辆能力自描述）、visualization（高频位姿）；导航模型 = node/edge 有向图 + base/horizon 渐进释放；位姿仅 x,y,theta,mapId（2D 平面 + 朝向）⁹。
许可证（双口径，落地需区分）：GitHub 仓库标 MIT（schema 等资产），但规范正文受 VDA 版权（注明来源方可复制）。
开源实现（逐个核实）：libVDA5050++（车端+主控两侧中间件库，C++，主仓 cmraaron、Fraunhofer IML 主导）¹⁰；InOrbit/Ekumen connector（车端 ROS2↔VDA5050 桥，BSD-3）¹¹；berketunckal/VDA5050-FleetManagement（主控/车队侧开源参考，Python+PostgreSQL）¹²；NVIDIA Isaac Mission Dispatch（VDA5050 兼容云端任务分派）¹³。Meili FMS 非开源（付费 license），不计入开源参考。
四足：明确面向 2D 轮式——无步态/roll-pitch/越障/3D 姿态/足端字段，路网假设也不适合非结构化地形 → 四足宜把 VDA5050 当语义骨架借鉴（order/state/factsheet/instantAction），不作直接目标协议。
借鉴什么：标准化 order/state 消息模型（厂商无关、版本化，轮式/四足共用语义骨架各自扩展字段）+ MQTT 解耦 + connection last-will 掉线检测 + factsheet 能力自描述（四足可扩步态/越障/姿态能力槽）+ instantAction 旁路通道（四足急停/姿态切换）+ base/horizon 渐进释放的路权分配思想。

🏭 商用车队管理 / 机器人运维系统（闭源标杆）

本体闭源，借鉴架构与对外接口范式，不借代码。

OTTO Motors / Rockwell Automation（OTTO Fleet Manager）：2023 年被 Rockwell 收购；做交通管理、派单、车队可视化。核心 Fleet Manager 闭源，但开源了 VDA5050 connector；OTTO 全系 AMR 已 VDA5050 认证、可被第三方主控纳管¹⁴。四足：仅 2D 轮式。借鉴：「业务系统 → 车队管理 → 车（VDA5050+MQTT）」三层解耦 + 开源 connector 可作 VDA5050 桥参考代码。（注：官方「REST」字样未逐字声明，标 UNVERIFIED。）
MiR Fleet（Teradyne 旗下，2018 收购）：事件驱动架构，官方称撑 100+ AMR；提供完整 REST API（面向 ERP/MES/WMS），且 API 文档内嵌产品界面可直接试调；闭源，但 VDA5050 Adapter（REST→MQTT 翻译层）开源¹⁵。四足：仅 2D 轮式。借鉴：「内部 REST + 外挂 VDA5050 adapter」解耦模式——正适合「内部自有协议、对外 VDA5050 接异构（含机器狗）」。（勘误：MiR 属 Teradyne 非 Zebra；Zebra 收的是 Fetch，后剥离给 Skild。）
Boston Dynamics Spot Orbit（原 Scout）— 四足运维标杆：Spot 四足机器狗的站点级机群管理软件，做任务调度、巡检数据归档、异常检测、自动回坞、条件触发；部署三态（Cloud / 本地 Site Hub 1U / VM-OVA）。对外接口（逐字确认）：✅ 官方 REST API（/api/v0/ 前缀）+ Webhooks（HMAC-SHA256 签名放 Orbit-Signature 头）+ Bearer Token¹⁶；软件本体闭源，Spot SDK（含 Orbit API 示例）GitHub BSD 开源。只管 Spot、无 VDA5050。借鉴：REST + Webhook(HMAC-SHA256) + Token 是自研对外接口黄金模板；「站点 + 任务调度 + 巡检归档 + 异常检测 + 自动回坞 + 工单集成」可直接作机器狗侧功能蓝本。
ANYbotics ANYmal — 四足原生：工业巡检四足 + 车队管理套件，边缘采集设备健康数据加密上传，开发中的 Workforce Suite（三角色权限模型）；对外 RESTful API（端点/认证细节未公开、标 UNVERIFIED），文档实际托管在 Siemens 开发者门户；闭源，与 Cognite/Yokogawa 等资产管理/数字孪生集成¹⁷。只管自家、无 VDA5050。借鉴：「边缘采集→加密→API 上传到资产管理/数字孪生」数据产品化路线 + 按角色分层权限。（注：未检索到「D-suite」独立产品，命名 UNVERIFIED。）
云深处 DEEP Robotics（绝影）：四足原生，绝影 Lite3/X20/X30 面向电力巡检、变电站、电缆隧道、应急；GitHub 有单机 SDK（robotserver_sdk MIT 明确是「控制并监控单台狗的导航任务」、XML/JSON over TCP）²¹。未检索到公开通用 fleet/多机调度 API（UNVERIFIED）。借鉴价值在场景定义，软件/API 不作接口标杆——恰印证国产四足缺统一开放车队软件。
宇树 Unitree：无官方统一车队/调度软件，只提供 per-robot SDK（unitree_sdk2，C++/Python，底层 CycloneDDS、兼容 ROS2），多机协同需自建²⁰。（辟谣：网传「Unitree fleet 平台」是第三方定制商营销文、非官方；eai.unitree.com 是数据/训练平台、非调度。）借鉴：印证「只有单机 SDK、没有车队软件」是常态——自研协同/调度软件是真实缺口；选宇树作机队成员需自研 adapter 封装其 DDS SDK。

🇨🇳 国产仓储 RCS / WCS（闭源；借鉴架构理念而非代码）

普遍闭源商业、API 不公开、基本只调自家车、不支持四足；可借鉴订单池 / 任务分配 / 交通管制 / 与 WMS 解耦的接口设计。

海柔 HAI Robotics（HAIQ）：调度核心 HAIQ，含 WES（业务执行）+ ESS（设备调度 RCS）+ 数据/仿真/算法平台，可独立运行或嵌入既有 WMS；ESS 标准任务接口=下发/取消/修改/状态回传；仅调自家 ACR/AMR²²。借鉴：业务执行层 ↔ 设备调度层解耦 + 标准任务接口契约。
快仓 Quicktron（RCS）：RCS 定位「车队中枢神经」，对上游 WMS/ERP/MES/MIS/OMS/TMS 解耦，主打数百台级交通流优化与防死锁²³。借鉴：纯 RCS 与 WMS 解耦的边界（最贴「自研只做协同调度」路线）+ 上游无关的通用任务模型。
极智嘉 Geek+（RMS）— 国产最接近「异构同池」：RMS（调度）+ WES（执行）+ IOP（运营）三层解耦；RMS 明确兼容 VDA5050 + 极智嘉自有协议双轨、可接合作伙伴第三方机器人、同质/异质混合调度（单场 >5000 台），提供开放 API + SDK，靠机器人建模能力统一调度多形态自家机型²⁴。借鉴：三层解耦 + VDA5050 双轨 + 机器人建模（把四足当一种新车型纳入异构调度的关键抽象）。
灵动 ForwardX（f(x)）：视觉 SLAM 无标识导航（无需二维码/反光板）+ 集群调度 + 人机协作拣选，向上对接 WMS/MES/ERP 有 API²⁵。借鉴：无二维码/磁条导航 + 人机协作任务分配 + 与上位系统解耦的 API 设计。
海康机器人（RCS-2000）— 国产标准化最高：RCS-2000(V4.0)+RCS-Lite，多车型混合调度，二开四件套（含异构对接低代码平台 iDataBus），并牵头国标 GB/T 43047-2023《物流机器人控制系统接口技术规范》（已发布、原文可查）²⁷。借鉴：接口标准化路线 + 低代码业务编排，南向接口可兼顾对齐 VDA5050 + 国标 GB/T 43047。
安歌科技 Enotek（原意欧斯 Eoslift）：WMS/WCS + AGV 调度（ADS），对接 DBLink/webservice/TCP-IP/OPC；闭源、只自家车、不支持四足²⁸。借鉴：WMS ↔ 调度解耦 + 多协议对接矩阵。（注意：搜索常见的 ant-robots 蚂蚁调度是另一家，与安歌无关。）
VDA5050 国产本地化：行业走「国标 GB/T 43047 + 新松等团标」路线推自有接口标准化；除极智嘉明确表态外，未见其它厂商官网明确「商用支持 VDA5050 + 异构第三方车」，标 UNVERIFIED、仅作趋势。

🔧 单机导航层 + 系统边界（自研定位）

ROS 2 Nav2（Navigation2）— 单机导航层，不要重造：单机器人自主导航栈（在 fleet adapter 之下），行为树编排的服务器集合（BT Navigator / Planner / Controller / Costmap / Recovery / Smoother / AMCL）；对外 ROS 2 Action 为主（NavigateToPose 等）+ 全插件化；以 Apache-2.0 为主（个别包 BSD/LGPL，逐包查）；官方明确支持腿足(legged)底盘³⁰，但 Nav2 只输出 cmd_vel 抽象，四足步态运动学需厂商运动栈承接。借鉴结论：单机导航直接用 Nav2，协同层只管调度（下发目标、订阅状态，把交通/派单/避让留给自研协同层）²⁹。
Fleet Adapter 设计模式：「每厂商/每车队一个适配器（防腐层）」——调度内核厂商无关，新增一种机器=新增一个 adapter、核心零改动。自研应直接照搬「厂商无关调度内核 + 每类机器一个 adapter」分层：机器狗写走 Nav2 action 的 adapter、外部 AGV 写走 VDA5050 的 adapter，切勿把某品牌私有协议硬编进调度逻辑。
WCS / WES / RCS / FMS / WMS 边界：WMS=业务/库存（分钟~~小时）；WES=执行编排（秒~~分钟）；WCS=固定自动化设备协调（毫秒）；RCS/FMS=移动机器人车队调度（秒~毫秒）。自研定位结论：协同调度明确放在 RCS/FMS 层（狗+AGV/AMR 异构任务分派 + 交通管制 + 避让 + 充电 + 监控），向上用标准接口对接客户既有 WMS/MES（不重做库存/订单），向下经 fleet adapter（含 VDA5050 client）连各类机器、单机用 Nav2。
WCS/WES 巨头边界（旁证）：Dematic（KION）iQ 融合 WMS/WES/WCS，移动机器人调度经 RCS/FMS 外接³¹；Siemens SIMOVE Fleetmanager 明确管理异构车队（不同品牌经 VDA5050 等协议统一纳管）³²。共性：巨头不重写每台机器的导航/运控，而是专注 WMS/WES/WCS、把车队调度交 RCS/FMS、异构机器统一用 VDA5050 接入——再次证明 RCS/FMS 层是开放空白区。

🎯 给自研的总结性架构建议

分层蓝图：业务（WMS/MES）→ 自研协同内核（RCS/FMS：派单 + 交通管制 + 避让 + 充电 + 监控） → Fleet Adapter（每类机器一个）→ 单机导航（Nav2）→ 厂商运动栈/步态控制。
核心设计模式：照搬 Open-RMF 的 Fleet Adapter + 三级集成（Full / Traffic-Light / Read-Only）；照搬 openTCS 的 Dispatcher/Router/Scheduler 策略抽象 + 模型驱动 + 通信适配器 + loopback 仿真。
对外接口：照搬 Spot Orbit 的 REST + Webhook（HMAC-SHA256）+ Bearer Token；openTCS 的 OpenAPI + API Key 可作模板。
南向协议：对外部 AGV/AMR 优先 VDA5050（参考 OTTO/MiR 开源 connector 的 REST↔MQTT 翻译层，可桥接进 Open-RMF）；机器狗因 VDA5050 偏 2D 轮式，宜走自研 adapter（借鉴 VDA5050 的 order/state/factsheet/instantAction 语义，扩展步态/姿态/越障字段）。
市场空白印证：宇树仅 SDK、云深处无公开通用 API、国产 RCS 均只调自家车——「机器狗 × AGV/AMR 异构协同调度层」是真实差异化空间。

⚠️ 诚实标注与勘误（撰文/对客户前注意）

openTCS 现行 license = MIT 已核实；早期是否 LGPL/GPL = UNVERIFIED。
libVDA5050++ 主仓在 cmraaron、Fraunhofer IML 主导；Meili FMS 非开源，真正开源主控参考是 berketunckal/VDA5050-FleetManagement。
VDA5050 许可证双口径：仓库 MIT（schema），规范正文受 VDA 版权。
MiR 属 Teradyne（非 Zebra；Zebra 收的是 Fetch）。
OTTO「REST」字样、ANYmal 端点级细节、云深处通用 API、多数国产厂商的 VDA5050 商用支持均 UNVERIFIED（厂商不公开），未编造。
Open-RMF 的 VDA5050 fleet adapter 为社区实验性、非官方核心，成熟度需自评。