优化前端，优化前端指令，优化自定义控制
This commit is contained in:
minghanchen
@@ -5,7 +5,7 @@
|
||||
`monitor-only` 桥，桥进程会拒绝所有发送请求。服务启动后由一个常驻监听线程
|
||||
持续缓存最新的已验证状态，HTTP 接口不会为每次前端请求反复开关 USB 设备。
|
||||
Linux 只读状态模式的前端刷新周期为 500 ms；缓存只保留 3 秒内的新鲜反馈，
|
||||
断线后会自动关闭旧桥并重试连接。监听通道只接受本文列出的 11 个标准帧 ID，
|
||||
断线后会自动关闭旧桥并重试连接。监听通道只接受本文列出的 12 个标准帧 ID，
|
||||
同时在 SDK 桥内保留同样的软件过滤，避免把无关总线流量转发给服务进程。
|
||||
|
||||
## 硬件和总线基线
|
||||
@@ -21,7 +21,8 @@ Linux 只读状态模式的前端刷新周期为 500 ms；缓存只保留 3 秒
|
||||
|
||||
前端车辆概况依赖 `0x342`（档位）、`0x4EB/0x07`（车速）和 `0x407`
|
||||
（门锁）。主驾座椅依赖 `0x4FA`、`0x494`。收到其他帧不能替代这些已验证
|
||||
反馈。
|
||||
反馈。车身设备还会按帧独立更新：`0x388` 四窗、`0x404` 空调、`0x41A`
|
||||
遮阳帘、`0x42E/0x3F3/0x3FF` 车内灯光，以及 `0x38A` 前部灯光。
|
||||
|
||||
## 前端有线 / 无线选择
|
||||
|
||||
@@ -29,7 +30,7 @@ Linux 只读状态模式的前端刷新周期为 500 ms；缓存只保留 3 秒
|
||||
|
||||
- 有线控制：状态和控制都走后端 ZLG CH1。
|
||||
- 无线控制：状态订阅 `n7/n7-headunit/can/state`，控制发布到
|
||||
`n7/can_control`；默认 Broker 为 `127.0.0.1:1883`。MQTT CAN0 专用于
|
||||
`n7/n7-headunit/can/command`；默认 Broker 为 `127.0.0.1:1883`。MQTT CAN0 专用于
|
||||
副驾座椅，MQTT CAN1 专用于除副驾座椅外的车辆状态和控制。
|
||||
|
||||
选择保存在当前浏览器，并随车辆状态请求和控制请求一起传给后端。切换传输时
|
||||
@@ -37,7 +38,8 @@ Linux 只读状态模式的前端刷新周期为 500 ms；缓存只保留 3 秒
|
||||
共用同一套编译范围检查、P 挡/零车速预检、反馈目标匹配和硬件批准令牌；MQTT
|
||||
发布成功只证明 Broker 接收了消息，不能替代 ECU 状态反馈。
|
||||
|
||||
MQTT 主题只承载原始 CAN 帧，不接受已经解析的车辆状态 JSON。规范帧格式为：
|
||||
MQTT 状态主题只承载原始 CAN 帧，不接受已经解析的车辆状态 JSON。接收侧继续
|
||||
兼容下面的规范单帧格式：
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -54,11 +56,36 @@ MQTT 主题只承载原始 CAN 帧，不接受已经解析的车辆状态 JSON
|
||||
}
|
||||
```
|
||||
|
||||
车机实际使用的 `n7-can-signals/v1` 状态包由顶层 `signals` 承载同样的原始帧。
|
||||
`n7/n7-headunit/can/state` 可以发送单帧对象，也可以发送
|
||||
`{"frames":[...]}` 批次。接收侧兼容 `can_id`、`canId`、`frame_id` 和
|
||||
`dataHex` 等常见字段名，但仍强制 CAN0/CAN1、11 位 ID、1–64 字节长度和
|
||||
逐通道反馈 ID 白名单。`n7/can_control` 始终由后端输出上述规范单帧格式，
|
||||
其中 `channel` 保留编译计划选择的通道。
|
||||
逐通道反馈 ID 白名单。
|
||||
|
||||
自然语言指令仍先由后端编译、检查白名单和车辆安全条件。每个已批准的 CAN 帧
|
||||
再转换为车机 App `CanCommand` 格式并发布到
|
||||
`n7/n7-headunit/can/command`：
|
||||
|
||||
```json
|
||||
{
|
||||
"requestId": "cognitive-agent-0e77879b83fd47a9bf12efb3d20dfae7",
|
||||
"channel": "can1",
|
||||
"canId": "0x431",
|
||||
"frameType": "fd",
|
||||
"brs": true,
|
||||
"extended": false,
|
||||
"remote": false,
|
||||
"data": "10 00 00 00 00 00 00 00",
|
||||
"repeat": 1,
|
||||
"intervalMs": 0,
|
||||
"responseTimeoutMs": 1500
|
||||
}
|
||||
```
|
||||
|
||||
每次发布生成不同的 `requestId`。MQTT 外层固定 `repeat=1`，原有执行器继续负责
|
||||
矩阵要求的重复次数、周期和动作后的安全停止，不会在车机端再次叠加重复发送。
|
||||
CAN0 输出 `classic` 且禁用 BRS；CAN1 按编译结果输出 Classic CAN 或合法长度的
|
||||
FD+BRS。车机按通道、控制 ID 和帧类型推断预期反馈 ID。
|
||||
|
||||
无线通道边界为：
|
||||
|
||||
@@ -82,7 +109,9 @@ MQTT 主题只承载原始 CAN 帧，不接受已经解析的车辆状态 JSON
|
||||
- CAN1 只以
|
||||
`/home/orin/project511/project-code/canfd/CAN矩阵表_filled.xlsx` 为准。
|
||||
例如 `0x42E` 颜色值只有 `0x01–0x1F` 有效，保留值不会显示为
|
||||
真实颜色。
|
||||
真实颜色。`0x388` 的四窗关好位按矩阵解析；byte 3–6 的四窗百分比另有
|
||||
`project-code/canfd/window_native.txt` 实车变化轨迹和车端原始帧证据，
|
||||
因此只有数值落在 `0–100` 时才显示为开度。
|
||||
|
||||
MQTT 消息自带的 `can0Seat.parsed` 和 `can1Vehicle.parsed` 只可用于车端
|
||||
诊断，后端不使用它们更新状态或通过安全门禁。
|
||||
@@ -159,9 +188,11 @@ make dev
|
||||
curl -s http://127.0.0.1:8000/api/runtime
|
||||
```
|
||||
|
||||
车辆状态接口应返回 `source=physical_can_ch1`、实际收到的
|
||||
`observed_frame_ids`，以及缺失反馈列表。发送成功、CAN ACK 和状态反馈是不同
|
||||
证据层级；只有接口实际收到并解码目标反馈才会更新前端。
|
||||
车辆状态接口在有线模式应返回 `source=physical_can_ch1`，在无线模式应返回
|
||||
`source=wireless_mqtt_ch1`，并包含实际收到的 `observed_frame_ids` 和缺失反馈
|
||||
列表。前端“整车设备状态”会把这两个来源都作为权威实时状态，并明确显示
|
||||
“有线 CAN”或“无线 CAN”。发送成功、CAN ACK 和状态反馈是不同证据层级；
|
||||
只有接口实际收到并解码目标反馈才会更新前端。
|
||||
|
||||
## SDK 自检
|
||||
|
||||
|
||||
Reference in New Issue
Block a user