Deconstructing the SEER System-Software Framework — A Reference Benchmark for Our In-House «Dog + AGV/AMR Coordination System Software» (Layered Architecture × External Interfaces × What to Borrow vs How Our In-House Build Maps to It · Working Draft Under Continuous Verification)

⚠️ Working draft under continuous verification, for in-house reference. Strategic premise (decided by the boss on 2026-06-29): the coordination system software for the robot dog and the AGV/AMR fleet will be built in-house by the company; SEER is not a procurement target but a reference benchmark — this piece thoroughly deconstructs the framework and composition of SEER's system software as a reference for our in-house build. Claims fall into three tiers: ① items explicitly stated on official product pages (HTTP API / WebSocket / callback / Python scripts / JavaScript scripts, M4's dispatch scale and traffic control, the tech stack) can be cited with confidence; ② items at the solution / media level (Modbus/OPC/S7 and other PLC protocols connected via M4, the VDA5050 bridge) are uniformly marked "to be verified," with no fabricated concrete endpoints; ③ naming collisions that must be untangled — Unitree D1 = a six-axis robotic arm (not a dog); the SEER family's D1/D2 = quadrupeds (partner hardware + SEER brain), not self-built complete machines. This piece is consistent with, and builds on, the conclusions of the repo's existing «SEER M4 Document Verification Report».

🧭 One-Sentence Overview

SEER carves the whole software stack into a two-layer decoupled shape: «per-robot autonomy pushed down into the controller, fleet dispatch lifted up into the cloud». The SRC controller is responsible for "how a single vehicle/dog moves" (mapping/localization/obstacle-avoidance/motion-control), while the M4 dispatch system only handles "which vehicle goes where, and who yields to whom" (order assignment/routing/traffic control). For our in-house build, this layering itself is the design most worth copying — swap hardware without touching dispatch, swap dispatch without touching the single robot; heterogeneous units (dog + AGV + AMR) can enter the same dispatch pool as long as they honor the same interface contract. But it has a fundamental limitation: the whole thing targets only 2D wheeled industrial AMRs — a dog's legged obstacle-crossing, 3D terrain, climbing slopes/steps are none of them in its dispatch model — and this is exactly where our in-house build must fill the gap and can surpass SEER.

Following the sister pieces: Feasibility of marsupial warehouse transport using the SEER system, Quadruped-AMR integration case list. This piece focuses specifically on «deconstructing the SEER system-software framework + how our in-house build maps to it».

🏭 Five-Layer Architecture (Text-Version Architecture Diagram)

L5 Toolchain Layer (Implementation / Simulation / Configuration)
   Roboshop Pro (low-code per-robot implementation: mapping/calibration/scripts/task sequences)
   Meta visualization series: Meta-Map(2D) / Meta-Map Pro(3D) / Meta-World(digital twin)
   Nebula (online configuration + solution setup + pre-validation in the digital world)
───────────────────────────────────────────────────────────
L4 Business / Integration Layer (M4 external-facing)
   Fully open HTTP API + callback  |  HTTP/WebSocket to connect ERP
   Modbus / OPC / S7 and other PLC protocols (to be verified)  |  VDA5050 bridge (to be verified, 2D wheeled only)
───────────────────────────────────────────────────────────
L3 Dispatch Layer (Fleet Brain) = M4 RCS / Fleet
   Multi-robot dispatch · dynamic order assignment · path planning · traffic control (collision-detection / Safe Swap)
   Stack = JVM(Java) + Rust/C++ high-performance components; Python(backend)/JS(frontend) dual-script extension
   Full-process simulation (hundreds of robots on an ordinary PC)  |  AI dispatch agent (natural language)
───────────────────────────────────────────────────────────
L2 Per-Robot Autonomy Layer (pushed down into the controller) = SRC series
   Mapping / localization & navigation / obstacle avoidance / motion control (fully autonomous per robot)
───────────────────────────────────────────────────────────
L1 Sensing / Actuation Layer
   Laser/vision sensors, steering-wheel/differential/forklift/legged actuators (90%+ mainstream parts already supported)

Core design philosophy (in one sentence): per-robot autonomy is pushed down into the SRC, fleet dispatch is lifted up into the M4, and the two layers communicate only through standard interfaces — whether a vehicle/dog has a built-in SRC or is a protocol-compliant third party, to the M4 it is a homogeneous "dispatchable unit"⁴.

📊 L3 Dispatch Layer: M4 (RCS / Fleet Management)

The M4 is the "fleet brain" of the whole system, and the most direct benchmark for our in-house dispatch layer. Capabilities given on the official product page (verified):

• Dispatch scale: supports "million-level storage locations, ten-thousand-level waypoints," and a single area can simultaneously dispatch 100+ units across multiple vehicle types, 300+ units of a single vehicle type²;
• Throughput: officially claimed "1000+ orders/minute, 10000+ orders/day"²;
• Task assignment: dynamic order assignment, nearest-takeover, reassignment, flexible dynamic batching, with priority/destination changeable mid-execution²;
• Traffic control (key): in-house collision-detection + Safe Swap traffic-control algorithm, covering scenarios such as full/empty load, oversized items, narrow aisles, rotational collisions, multi-vehicle collisions, close-quarters queuing, and head-on meeting²;
• Configuration effort: officially claimed "80% reduction in configuration"²;
• Simulation: one-click simulation of hundreds of robots on an ordinary PC, including device simulation + collision detection²;
• AI dispatch assistant: a natural-language multi-robot dispatch-management agent ("world's first/first-to-market" is the vendor's own marketing claim, cited as advertised)¹.

M4 tech stack (the segment with the most reference value for our in-house build, verified)³:

• The backend is based on the JVM (Java), with some high-performance components in Rust / C++, compatible with mainstream operating systems + ARM;
• The frontend is React, with all components built in-house and no reliance on third-party UI libraries;
• A dual-script extension model: extend backend functionality with Python, extend frontend pages with JavaScript, with most updates requiring no restart;
• The selling point is "all customers share the same core version while each maintains their own customized business logic" — even long-standing customers get the latest kernel updates;
• An in-house persistence engine (multi-database, auto-create/alter tables on startup) + an in-house fully automatic cache layer (intercepting 90%+ of database requests);
• The key dispatch component (Falcon) supports crash recovery and resume-after-crash.

🔧 L2 Per-Robot Autonomy Layer: the SRC Controller Series

The SRC is the "robot's brain," integrating core functions such as mapping, localization & navigation, and model editing; a third-party vehicle/dog with a built-in SRC can be uniformly connected into M4 dispatch, and it is already adapted to 90%+ of mainstream parts manufacturers and serves over a thousand customers⁴.

Model tiers (per the official controller page and the WRC exhibitor page):

⚠️ Errata (must be followed): the controller for a dog / embodied use can only be the SRC-5000; the SRC-1100 is a dual-steering-wheel controller, not for quadrupeds.

SRC-5000 specs (WRC 2025 exhibitor page): interfaces include high-speed network ports / EtherCAT / GMSL cameras; compute of 156 TOPS (with NVIDIA edge AI); navigation 2D/3D + VSLAM + hybrid; real-time system + Time-Sensitive Networking (TSN), 250μs synchronization cycle; multi-modal obstacle avoidance; solves coordinated control of "locomotion + manipulation," supporting composite robots / wheeled humanoids; the quadruped robot dog equipped with it can handle complex terrain¹⁰.

🛞 L5 Toolchain Layer: Roboshop / Meta-World / Nebula

• Roboshop Pro (low-code per-robot implementation tool): a one-stop implementation client for mobile robots, with functions including SLAM mapping, map/site/route/area editing, automatic calibration, robot model editing, parameter configuration, log analysis, online scripting, task-sequence editing, and dispatch-scenario editing, with the selling point "low-code engine + online scripting, so even novices can DIY"¹¹. It is the configuration/debugging frontend for a single SRC, and is a different level of low-code from M4's fleet-level low-code (Falcon tasks).
• Meta-World (digital twin): the Meta visualization series includes Meta-Map (2D) / Meta-Map Pro (3D) / Meta-World (digital-twin solution); Meta-World models the real scene 1:1 accurately, with the twin world and real-world data synced in real time, enabling virtual commissioning and intuitive decision-making⁷, and works with M4 for real-time monitoring and solution pre-validation⁸.
• Nebula (online configuration platform): online configuration + solution setup, with all-around customization of function/structure/appearance, a vast out-of-the-box physical model library, and "validating real solutions ahead of time in the digital world," covering the full lifecycle from solution planning to long-term operation⁹. (The SKU count in the official copy changes at any time, roughly "1000+~2000+ items"; citations must note the point in time.)

🤖 L4 External-Interface List (the layer our in-house build should benchmark most)

Honest framing: API / WebSocket / callback / Python / JS — these five are explicitly stated on official product pages and trustworthy; the concrete protocol lists and endpoints for Modbus/OPC/S7/VDA5050 are uniformly marked as solution-level / to be verified, and never fabricated.

🎯 «What to Borrow vs How Our In-House Build Maps to It» Comparison Table

⚠️ SEER's Limitations = Our In-House Opportunity Windows

1. Targets only 2D wheeled industrial AMRs: dispatch, traffic control, and VDA5050 are all planar assumptions. A dog's legged obstacle-crossing, 3D terrain, climbing slopes/steps, posture are none of them in its dispatch model → our in-house coordination system must bring "heterogeneous kinematics (wheeled vs legged)" into dispatch and traffic control, doing area locks/intersection arbitration/avoidance differentially according to a "vehicle-type capability profile."
2. VDA5050 is not explicitly stated on the M4 product homepage and is mentioned only on solution/media pages (to be verified), and the standard itself does not cover legged motion — our in-house build can simply treat VDA5050 as an external-compatibility option, with a custom core protocol.
3. The SEER family's D1/D2 quadrupeds are not self-built complete machines — they are a co-branded/solution-level arrangement of "partner-built hardware + SEER-supplied brain (SRC-5000 + navigation)," with no standalone quadruped SKU on the official product page. This shows that SEER itself has not turned "quadruped" into a mature standard product line, leaving our in-house build a chance to differentiate on "dog + AGV in the same dispatch."
4. SEER has no local agent in Japan (only a German subsidiary; the Japanese-language site still routes inquiries to headquarters) — if the target market includes Japan, our in-house build has room on localization and on-site service.
5. The developer API doc site is not publicly reachable directly (direct link 404 / portal 000), so the visibility of its external ecosystem openness is weak; our in-house build can make open docs publicly reachable, improving the integration ecosystem.

📦 Two D1s That Must Be Untangled (Avoiding Confusion)

• Unitree D1 / D1-T = a six-axis teleoperated robotic arm (about 2.37kg, 500g payload), not a dog¹².
• The SEER family's D1 / D2 = quadruped robot dogs (partner hardware + SEER brain), unrelated to the Unitree D1.

🧭 One-Sentence Conclusion for Our In-House Build

The most worthwhile thing to copy from SEER is not any single feature but its shape: per-robot autonomy and fleet dispatch are thoroughly decoupled into two layers, the external surface exposes only a stable contract of HTTP/WebSocket/callback + script extensions, and a single-version kernel does customization through a script layer. If our in-house system follows this skeleton and then thickens up its blind spot — bringing heterogeneous kinematics (the dog's legged motion / 3D terrain) into dispatch and traffic control — we can stand on SEER's mature design while filling in its fundamental shortcoming of "targeting only 2D wheeled vehicles."