Marsupial (Mother-Child) Vehicle Collaboration: After Building Our Own System Software, Do We Still Need Add-On Hardware Between the Child/Mother Vehicles?——Software Interface vs. Physical Docking Boundary × Which AGV/AMR Unitree GO2/B2 Can Dock With Add-On-Free × Cost Order-of-Magnitude (Working Draft to Be Verified)

⚠️ Working draft to be verified. This piece integrates the boss's consulting draft "Does Marsupial-Vehicle Collaboration System Software Still Need Add-On Hardware" with this project's research, corrected per our established conventions: only Unitree's EDU edition opens full low-level secondary development (consumer Air/Pro are basically locked); the exact interface counts and compute of GO2/B2 should follow the official spec pages; prices are order-of-magnitude estimates only, varying by channel and time; all external links were curl-tested (support.unitree.com returns a 567 anti-scraping code but is reachable in a browser, not a dead link). Continuing the sister pieces: Using the SEER system for marsupial-vehicle warehouse transport, GO2 starter selection · integration, Coordination software landscape.

🧭 One-Line Overview

The answer hinges on one thing: whether you want the mother vehicle to "physically carry" the child dog.

• If you need physical carrying (the mother vehicle hauls the dog around) → mechanical docking hardware is unavoidable: carrier deck, boarding/disembarking ramp, locking mechanism, (optional) charging contacts—no matter how perfect the software, it can't replace these.
• If you only need logical collaboration / relay (the dog walks on its own, the AGV drives on its own, software just unifies scheduling) → almost no dedicated add-on hardware is needed; the software interface plus the off-the-shelf sensors on both sides is enough.

And there's a key upside: the two hardware categories of communication and compute are already fully built into Unitree GO2 EDU / B2 (gigabit Ethernet port, Wi-Fi, Orin/i7 compute), so when acting as a "child vehicle" it basically needs no add-on communication chips or compute boxes—just define the software interface and it can talk directly. The only things truly "unavoidable" are the mechanical docking parts required for physical carrying and the safety hardware cutoff.

🧠 First, Clear Up a Misconception: "Interface" and "Docking" Are Two Different Things

A software interface defines the "rules of conversation"—API, communication protocol, scheduling timing (who goes where, when to dock, how tasks are handed off). But software can't move atoms: to make the mother vehicle actually "lift" the dog, keep the dog "standing firm without falling off," and let the dog "disembark and go upstairs," there must be physical mechanisms to carry out the actions.

So "defining the interface" ≠ "no hardware needed." The role of the interface is to let your software command the hardware and read the hardware's feedback; the hardware that performs the actions still has to exist. This is precisely the boundary of standards like VDA5050—it only solves logical-layer vendor-agnostic interoperability (dispatch/reporting), and handles no mechanical docking whatsoever¹⁰.

🔧 Going Through the Five Hardware Categories: Which Are Built In, Which Must Be Added On

Conclusion: the Unitree dog ships ①② out of the box—the two hardware categories "a software company most dreads building itself" (communication + compute). What you really need to add is ④ physical carrying mechanical parts (and only on the carrying route) and ⑤ safety hardware cutoff, with ③ alignment markers added per precision requirements.

🛞 Two Routes: Whether to "Physically Carry" Determines the Hardware Volume

Plan A: True Marsupial Vehicle (Mother Physically Carries the Child Dog)

Mechanical docking hardware is unavoidable: carrier deck + boarding/disembarking ramp/rails + alignment guidance (AprilTag/rails, docking precision needs ≥99.9%) + locking mechanism (otherwise the dog falls off the moment the mother vehicle turns or climbs) + (optional) charging contacts. On this route the docking mechanism is the hardest, most reliability-critical part of the whole setup—but communication/compute can still rely entirely on the Unitree dog's built-ins.

Plan B: Logical Collaboration / Relay (No Physical Carrying)

The dog walks on its own, the AGV drives on its own, and software only does unified scheduling and the relay—for example, the AGV transports goods to the stairwell/foot of the ramp, and the dog takes over the relay from there to go upstairs.

• Almost no dedicated docking hardware needed: the software interface plus the off-the-shelf sensors on both sides is enough;
• The only thing you might need is a fixed charging dock (not added onto the vehicle) and a transfer mechanism at the goods-handoff point (if goods need to change hands between dog ⇄ vehicle).

→ Plan B has the least hardware and the highest software value, best suited for a company that wants to differentiate through software to start with; only when the load weight/scenario is settled and carrying is genuinely required do you bring in Plan A's mechanical docking parts. This also echoes the horizontal-research conclusion: what the market lacks is this layer of heterogeneous-coordination scheduling software, not docking ironware.

📦 Unitree GO2 / B2 as a "Child Vehicle": Why Communication/Compute Need No Add-Ons

The Unitree quadruped is itself a highly integrated mobile edge-compute platform, and once you pick the right edition, the communication and compute interfaces are "spilling over":

• GO2: built-in Wi-Fi + Bluetooth; the official expansion dock provides a standard gigabit Ethernet port (RJ45) / USB; the EDU edition can option in NVIDIA Jetson Orin compute, enough to run RC algorithms locally¹. ⚠️ But only the EDU edition opens full low-level secondary development—consumer Air/Pro are basically locked, so integration must use EDU (see GO2 starter selection).
• B2 (heavy-load industrial dog): the body directly provides multiple gigabit Ethernet ports, USB, 5V/12V/24V power, and general-purpose GPIO, ships with an Intel processor internally, and can stack an NVIDIA Orin NX². It has the most complete industrial interfaces and is best suited for the role of "both a child vehicle and self-equipped with safety I/O."
• Secondary development goes via the official SDK / ROS2: the entire Unitree line natively supports ROS2⁶, the community also has a mature GO2 ROS2 driver to reference⁷, controller/interface materials are in a third-party documentation site⁸, and the developer portal is on the official support site⁵.

In one line: with Unitree GO2 EDU/B2 as the child vehicle, the communication and compute hardware really doesn't need to be added on—define the software interface and it can communicate outward, provided you choose the EDU/industrial edition.

🤖 Which AGV/AMR the Unitree Dog Can Directly Connect To (as the "Mother Vehicle")

As long as the mother vehicle supports industry-standard network protocols and opens low-level APIs (especially ROS/ROS2), no extra hardware is needed—one Ethernet cable or Wi-Fi connects directly:

1. ROS2-native chassis (the most perfect direct connection): the entire Unitree line is natively ROS2⁶, and the market has plenty of ROS/ROS2 standard chassis to mount a dog on directly. Representatives: AgileX (Scout / Bunker series wheeled/tracked chassis)⁹, and internationally Clearpath, etc. Connection method: an Ethernet cable links the dog's RJ45 to the chassis controller, and both sides talk directly over ROS2 Topic/Service—the dog reads the chassis odometry/velocity (control variables), and the chassis follows the dog's navigation commands.
2. Commercial AMRs with open HTTP WebAPI / Modbus TCP: modern laser-navigation AMRs mostly open network interfaces on the onboard controller. Representatives: MiR¹¹, Geek+¹², Hikrobot¹³, Quicktron¹⁴. Connection method: via its own Wi-Fi/Ethernet, the dog sends JSON commands to the mother vehicle ("stop at shelf X") or reads the mother vehicle's coordinates.
3. I/O GPIO hard-coupling (high-reliability tight coupling): when you worry about network packet loss, B2's multiple 24V/12V power and general-purpose GPIO lines can use physical contacts that close when "the dog lies down on the mother vehicle," delivering a high/low logic level to the mother vehicle's controller²—latency near 0 milliseconds, best suited as the highest-priority signal for safety lockout and emergency braking.

⚠️ Honest note: the AGVs above being "directly connectable" refers to the logical/communication layer being able to talk via standard protocols; if you want the mother vehicle to physically carry the dog, you still need to add Plan A's carrier/locking mechanical parts on the mother vehicle—network connectivity and mechanical carrying are two different things. Each AMR's exact API specs should follow the vendor documentation (mostly project-based access; see Coordination software landscape).

📊 Add-On Hardware Cost (Order-of-Magnitude Estimate Only, Not an Official Quote)

Prices vary several-fold by brand, industrial protection rating (IP65/67), intrinsic-safety certification, channel, and time—used only to judge orders of magnitude, not as a quote.

Cost-saving point: using Unitree GO2 EDU/B2 as the child vehicle, the communication + edge-compute tiers are basically eliminated (built in); what remains is mainly alignment sensing (per precision) + safety mechanism + (only on the carrying route) mechanical docking parts.

🎯 Implementation Recommendations for the Self-Build + NEDO Proposal

1. Validate the software loop with Plan B first (fastest, cheapest, best at demonstrating the moat): the dog and the AGV each manage their own legs, and software only does heterogeneous scheduling + relay orchestration; bring in Plan A's mechanical carrying parts once the load weight/scenario is settled.
2. Push hardware cost to the minimum as a selling point: emphasize "no need to modify existing industrial AMR hardware, fully leveraging Unitree's native gigabit Ethernet port and high-compute edge platform"—precisely the low-cost social-implementation viability NEDO prefers.
3. Plug into the company's RC edge anomaly-detection moat: on the child/mother vehicle, use the Unitree dog's built-in ROS2 interface to capture control variables (motor current, joint torque, LiDAR distance), run RC (Reservoir Computing) ridge-regression anomaly detection on the built-in Orin, and issue a braking command milliseconds before the dog is about to derail/jam—detecting "track micro-deformation/slip conflict" at the instant of the mother-child handoff is an excellent implementation scenario (plugging into the company's existing Demo and NEDO track record; see Team's existing assets · RC edge AI).
4. Back up safety with hard I/O: use B2's GPIO physical contacts for 0-latency e-stop/lockout, as the highest-priority hard protection on top of software detection.

⚠️ Honest Notes and Corrections

• Only Unitree's EDU/industrial edition opens full low-level secondary development; consumer Air/Pro are basically locked, and integration must choose EDU—don't plan around the consumer edition.
• The interface counts and compute configuration of GO2/B2 should follow the official spec pages; this piece's interface descriptions synthesize the official pages and third-party docs, with the as-installed measurements/official docs taking precedence.
• All prices are order-of-magnitude estimates, not official quotes, varying several-fold by channel and time.
• "Can directly connect to an AGV" = logical/communication layer; physical carrying still needs mechanical docking hardware—don't conflate the two.
• VDA5050 only handles logical-layer interoperability, not mechanical docking; and it only targets 2D wheeled vehicles (see Coordination software landscape).
• The support.unitree.com developer portal returns 567 on curl (anti-scraping code, reachable in a browser, not a dead link).