EmbCom · 具身智能传输中间件

序言
内容导览
01产品定位与设计理念
[02为什么需要 EmbCom ------ 具身智能的四大传输痛点](#02为什么需要 EmbCom —— 具身智能的四大传输痛点)
03产品总体架构
04核心能力一览
[05QUIC 四信道协议设计](#05QUIC 四信道协议设计)
[06大文件传输引擎 ------ 为具身智能大文件而生](#06大文件传输引擎 —— 为具身智能大文件而生)
07弱网可靠性三件套
[08平台生态适配 ------ 已完成真实环境验证](#08平台生态适配 —— 已完成真实环境验证)
[09SDK 与调用方式 ------ 五个动词，像 Redis 一样简单](#09SDK 与调用方式 —— 五个动词，像 Redis 一样简单)
10性能实测报告（真实环境，非理论值）
11与主流方案对比
12典型应用场景
13部署形态与运维
14产品路线图

序言

内容导览

01产品定位与设计理念

Redis 解决了"内存场景"的标准化，WebRTC 解决了"浏览器音视频"的标准化，EmbCom 要解决的是具身智能"传输场景"的标准化。机器人公司不再需要各自造轮子拼装 MQTT + RTSP + FTP + 私有 TCP，而是引入一个中间件，用五个动词完成全部通讯。

02为什么需要 EmbCom ------ 具身智能的四大传输痛点

03产品总体架构

四层架构：客户端 SDK 层 → 中间件服务层 → 平台适配层 → 生态平台层。embcomd 是核心，对上承接 SDK，对下桥接厂商平台。

04核心能力一览

05QUIC 四信道协议设计

一条 QUIC 连接内逻辑划分四条信道，各取所需：可靠的走流（Stream）、要快的走数据报（Datagram）。

控制报文示例（遥测，线格式 106 字节）

c 复制代码

{"t":2, "s":1024, "ts":1757385600000, "p":{"x":12.34,"y":56.78,"yaw":1.57,"bat":86,"state":"WORKING"}}  // CBOR 短键编码后 106B，同内容 JSON ≈ 320B

06大文件传输引擎 ------ 为具身智能大文件而生

07弱网可靠性三件套

机器人工作在电梯、地下车库、厂区边缘等弱网环境。EmbCom 把"断网"当作常态而非异常来设计。

08平台生态适配 ------ 已完成真实环境验证

09SDK 与调用方式 ------ 五个动词，像 Redis 一样简单

EmbCom 的全部能力收敛为五个动词：Dial / Publish / Subscribe / Upload / Download（外加 SendMedia 发媒体帧）。

go 复制代码

// Go SDK ------ pkg/embcom
c, _ := embcom.Dial("edge-box:9000", embcom.WithIdentity("s95-001", "s95"))

c.Publish("telemetry", data)                    // 发布遥测
c.Subscribe("command", handler)              // 订阅指令

ack, _ := c.Upload("map", "park.usd", data)   // 上传地图（zstd+SHA256，等回执）
data, meta, _ := c.Download("map", "park.usd") // 下载地图（自动校验）

c.SendMedia(0, frame, true)                  // 发送视频帧（datagram，关键帧标记）
// Rust SDK ------ embcom-rs（端侧机器人，低资源场景）
let c = Client::connect("edge-box:9000", "s95-001", "s95").await?;
c.publish("telemetry", &data).await?;
c.subscribe("command", handler).await?;
c.upload("map", "park.usd", &data).await?;
let (data, meta) = c.download("map", "park.usd").await?;
c.send_media(0, &frame, true).await?;  // 与 Go 线格式完全互通