54 lines
2.1 KiB
Markdown
54 lines
2.1 KiB
Markdown
# 通信场景说明
|
||
|
||
## 系统拓扑
|
||
- 系统中有 `A/B/C/D` 四个终端。
|
||
- `A` 与 `C` 在同一侧，`B` 与 `D` 在同一侧。
|
||
- 实际运行时不是一条端到端 KCP，而是两条独立 KCP 链路：
|
||
- `B <-> D`
|
||
- `D <-> A`
|
||
- `C` 只负责 UDP 端口转发。
|
||
- 整体目标是让 `A` 与 `B` 双向通信：
|
||
- `A -> B` 发送控制命令
|
||
- `B -> A` 发送视频和其他反馈数据
|
||
|
||
## 网络情况
|
||
- 主要瓶颈在 `B` 侧 5G 链路，`A` 侧是有线网络，不是主要约束。
|
||
- `B <-> D` 的时延抖动较大：
|
||
- 常见约 `15-60 ms`
|
||
- 最差约 `80-90 ms`
|
||
- 带宽是明显非对称的：
|
||
- `B -> D` 约 `8 Mbps`，偏低且不稳定
|
||
- `D -> B` 约 `27-50 Mbps`，更高但也有波动
|
||
- 工程含义：
|
||
- 控制流必须优先保障
|
||
- 视频流必须限速并具备自适应能力
|
||
- 不能默认把所有流合成一个共享传输就一定更优
|
||
|
||
## 三个项目的角色
|
||
- `OmniSocketGo`
|
||
- 底层传输项目
|
||
- 使用 C 编写
|
||
- 提供 OmniSocket/KCP 传输能力，以及视频发送等原生传输程序
|
||
- `robot-command-center`
|
||
- A 侧上层应用
|
||
- 主要负责接收视频帧，并提供监控/展示能力
|
||
- 当前通过本机 `A-side OmniDaemon` 使用传输能力
|
||
- `tienkung-szu`
|
||
- 上层控制项目
|
||
- 同时包含 A 侧控制发送和 B 侧控制执行逻辑
|
||
- A 侧典型入口是键盘/Xbox sender
|
||
- B 侧典型入口是 `rl_control_node.py` / `rl_control_node_sim.py`，负责接收控制并驱动机器人行为
|
||
|
||
## 当前架构方向
|
||
- `A` 侧通过 `A-side OmniDaemon` 统一管理本机的控制发送和视频接收。
|
||
- `B` 侧通过 `B-side OmniDaemon` 统一管理本机的控制接收和视频发送。
|
||
- 核心原则：
|
||
- 控制流与视频流逻辑分离
|
||
- 每台主机通过本地 daemon 统一持有传输会话
|
||
- 后续围绕真实网络瓶颈做 telemetry、调度和速率自适应
|
||
|
||
## 代码原则
|
||
- 一定要精简，不能写过于复杂和冗余的代码，因为必须确保各个环节可控，在低延迟的要求下，需要细化各个环节的消耗
|
||
|
||
## SSH原则
|
||
- 如果你需要SSH到某个远程端执行操作，一定要确保不做删除文件操作，确保留有记录 |