⚠️ This is an architecture draft, not a product spec. Its purpose is to take the conclusion that keeps appearing in the sibling articles — "carrier-vehicle integration can only be self-built middleware" — and turn it into a minimal diagram you can build to. The interfaces/protocols listed (unitree_sdk2's DDS, VDA5050's MQTT/JSON) follow each SDK's/standard's official docs and real PoC verification; the links here are curl 200. "Minimal" = PoC scope, deliberately drawing only the modules needed to close one loop — no production-grade redundancy / safety certification / multi-robot dispatch scaling (those come in phases 2/3).
🌐 What this answers
Two sibling articles point at the same sentence: GO2 selection says "GO2 has no ready AMR solution; integration must be self-built — which is exactly the differentiation"; SEER M4 landing path says "even without a SEER deal, use it as a benchmark and self-build." So what does 'self-build' actually build? This article draws it as a minimal architecture + a work sequence, as the technical starting point of PoC phase 1.
Carrier-vehicle concepts/cases → Marsupial research; the three fusion forms → Fusion; the buy-it-ready path → SEER M4 landing path.
🧱 1. Why "self-built middleware" (one line, picking up the conclusion)
- Robot dogs (GO2/B2 etc.) have no ready AMR-docking product and don't support VDA5050 (VDA5050 targets 2D wheeled AMRs only) — see GO2 selection.
- So in the "AMR carries dog, dog climbs stairs" loop, the orchestration, docking and cooperation between carrier and child have no off-the-shelf protocol — you must write a middleware layer yourself.
- That layer is the business plan's "software × hardware" moat: the hardware (AMR, dog) is all bought off the shelf; the orchestration is ours. SEER turned this into a product (see SEER article); self-building means "build a mini, fully self-controlled version."
🗺️ 2. The minimal architecture (one diagram, three layers)
╔══════════════════════════════════════════════════════════════════╗
║ In-house middleware / dispatch-orchestration (core, all ours) ║
║ ║
║ ┌───────────────┐ ┌───────────────┐ ┌────────────────────┐ ║
║ │ Task state │ │ Map / Localize │ │ Docking cooperation │ ║
║ │ machine │ │ fusion │ │ handshake protocol │ ║
║ │ (deadlock-free)│ │ (carrier↔dog) │ │ (mount/dismount) │ ║
║ └───────┬───────┘ └───────────────┘ └─────────┬──────────┘ ║
║ │ Monitoring / HMI / logs / alerts │ ║
╚═══════════╪═══════════════════════════════════════════════╪═══════╝
│ │
① carrier I/F │ VDA5050 (MQTT/JSON) or vendor API ② child I/F │ DDS/ROS2/WebRTC
│ │
┌────────▼─────────┐ ═══ docking ═══ ┌────────▼──────────┐
│ Carrier AMR │ physical interface + │ Child robot dog │
│ (off-the-shelf · │◄── charge/re-seat/lock ──►│ (start w/ GO2 EDU) │
│ wheeled) │ │ stairs·last-100m │
│ heavy load·flat │ └───────────────────┘
└──────────────────┘ unitree_sdk2 / unitree_ros2
existing AGV reusable
Three reading points:
- The two side interfaces are heterogeneous: the carrier uses the industrial-AMR stack (VDA5050 or vendor API), the child uses Unitree's stack (DDS/ROS2) — the middleware's first job is to translate both into one internal task language.
- The most valuable piece is the orchestration layer: it produces no hardware capability; it produces "when, who, does what, how to hand off" — that is the in-house software.
- Docking is physical + protocol, two layers: a mechanical interface (mount/dismount, lock, optional charge) and a software handshake (the carrier may only move once the dog is confirmed seated/dismounted) — safety interlock lives here.
🔌 3. Per-layer interface checklist (what self-building actually targets)
| Layer | Module | Interface | Source / note |
|---|---|---|---|
| Child comms | motion commands / read sensors | unitree_sdk2 (CycloneDDS) | 1 |
| Child comms | ROS2 ecosystem bridge | unitree_ros2 | 2 |
| Child comms | Python rapid prototyping | unitree_sdk2_python | 3 |
| Child comms | Wi-Fi/Ethernet dual (community ref) | go2_ros2_sdk (WebRTC+DDS, no fleet) | 4 |
| Carrier comms | standard dispatch protocol | VDA5050 (MQTT/JSON; needs carrier support) | 5 |
| Carrier comms | fleet-manager reference impl | openTCS VDA5050 adapter | 6 |
| Orchestration | task state machine / deadlock-free | in-house (Petri-net per marsupial lit.) | see Marsupial research |
| Orchestration | docking handshake / safety interlock | in-house (physical + protocol) | this article |
| Comparison | buy the equivalent ready | SEER M4 (quadruped + VDA5050 one system) | 7 |
Low-level control needs EDU: to write custom gaits / fine docking, the child must be GO2 EDU (includes low-level
rt/lowcmd; Air/Pro are locked) — see GO2 selection.
⏱️ 4. Work sequence (one deadlock-free loop)
Decompose "AMR carries dog, dog climbs" into a state machine, each step with enter/exit conditions, made deadlock-free per the marsupial literature (Marsupial research):
[IDLE]
│ task received (target floor/point)
▼
[AMR_DRIVE] carrier ferries dog on flat to the stairwell ──(arrived)──►
[ARRIVE] carrier parks·localization aligned ──(check OK)──►
[WAKE_DOG] middleware wakes dog·sends task coords ──►
[DOG_DISMOUNT] docking unlock·dog dismounts ──(confirm off)──►
[DOG_TASK] dog climbs/last-100m/haul·recognize ──(task done)──►
[DOG_RETURN] dog autonomously returns to the docking face ──►
[DOCK] docking handshake·lock·(optional charge) ──(confirm seated)──►
[AMR_DEPART] carrier ferries dog to next point / homes ──► [IDLE]
exception branch (any step fails)→[SAFE_HOLD] stop·alert·human intervention·carrier must NOT move an unseated dog
The first iron rule of safety:
[AMR_DEPART]'s precondition is the docking handshake confirming "dog seated" — this interlock prevents the carrier from dragging an unseated dog, the minimal safety a PoC must still have.
⚖️ 5. Self-build vs buy SEER (two implementations of the same diagram)
| Dimension | Self-built middleware (this) | Buy SEER (SEER article) |
|---|---|---|
| Orchestration layer | in-house from scratch (state machine + docking handshake) | M4 ready (quadruped + VDA5050 one system)7 |
| Child motion control | unitree_sdk2/ROS2 wired by us | SRC controller ready |
| Bridge existing AGV | self-written VDA5050/vendor API bridge | M4 via VDA5050 |
| Self-control | ✅ fully autonomous | ⚠️ depends on SEER (no Japan agent) |
| Startup cost/timeline | ⚠️ high (write it yourself) | ✅ low (buy ready) |
| Differentiation moat | ✅ orchestration is in-house IP | ⚠️ orchestration is SEER's |
| Recommendation | In the GO2 PoC, self-build a mini version first (lowest-cost loop validation + accrue in-house IP) | At scale / heavy heterogeneous, then evaluate M4 as the unified RCS |
Not mutually exclusive: self-build the mini version first to accrue the loop and the in-house IP; if SEER is cheaper at scale, the orchestration experience migrates cleanly to "M4 + our upper-layer business."
🪜 6. The 3-phase PoC mapping (how to build the diagram in stages)
- Phase 1 (single unit · minimal loop): GO2 EDU + one off-the-shelf AMR + the "minimal subset of the orchestration layer" from this diagram (state machine + docking handshake), closing "drive→dismount→climb→return→dock→depart." Lowest failure cost.
- Phase 2 (in-plant prototype): add map/localization fusion + monitoring HMI, against UISEE × State Grid "car-dog integrated" on a real in-plant route.
- Phase 3 (connect the fleet / upgrade to heavy load): once load is known, swap the heavy segment to B2/B2-W, bridge the carrier to Otsuka's existing AGVs (VDA5050), or evaluate going fully to SEER M4 — the phase 1/2 orchestration stack migrates as-is.
⚠️ For you to verify / to add
- Want me to export this diagram as SVG/PNG for the client proposal (docx/ppt) technical page?
- Carrier selection: which off-the-shelf AMR for phase 1 (an existing Otsuka unit or buy a light AMR for the PoC) — give me the model and I'll firm up the carrier-interface row (VDA5050 vs vendor API).
- Docking mechanism: want a separate design draft for "mount/dismount mechanism + safety interlock" (incl. a charging-dock option)?
- Real route/load: once known, I'll work out the per-step timeout/retry params and the GO2→B2 upgrade threshold.