vee
54 lines
3.4 KiB
Markdown
54 lines
3.4 KiB
Markdown
# T2G 座椅与车身双通道 CAN 联动
|
||
|
||
## 集成基线
|
||
|
||
- 座椅控制沿用当前仓库的 IAR `Seat_Controller_demo` 协议与闭环回读。
|
||
- 车身控制从 `https://git.kendeji.fun/dev-team/project-code` 的 `CAN_DEV` 分支导入，固定基线为提交 `6e7ed04a468dfcde7efda9e30bc15144bf02faf9`。
|
||
- 不允许自然语言直接提供 CAN ID 或原始载荷；只有能力目录中命名、经过范围校验的动作可以编译到车身 CAN。
|
||
|
||
## 适配器和通道
|
||
|
||
一个 `USBCANFD-200U` 只由一个 32 位桥接进程打开一次，再向应用暴露两个通道视图：
|
||
|
||
| 通道 | 用途 | 帧格式 | 仲裁速率 | 数据速率 |
|
||
|---|---|---|---:|---:|
|
||
| CH0 | T2G 副驾座椅控制器 | 11-bit Classic CAN | 500 kbit/s | — |
|
||
| CH1 | 空调、车窗、门锁、灯光、遮阳帘和电动风口 | 11-bit ISO CAN FD；按报文选择 BRS | 500 kbit/s | 2 Mbit/s |
|
||
|
||
车身通道使用 60 MHz CAN 时钟。仲裁段为 `tseg1=14, tseg2=3, sjw=2, smp=0, brp=5`，20 TQ、80% 采样点；数据段为 `tseg1=10, tseg2=2, sjw=2, smp=0, brp=1`，15 TQ、80% 采样点。ZLG 运行时使用驱动内置的 `500000`/`2000000`、80% 参数项，并显式选择 Normal、ISO CAN FD。
|
||
|
||
## 服务端配置
|
||
|
||
```powershell
|
||
$env:COGNITIVE_AGENT_HARDWARE_EXECUTION_ENABLED = "true"
|
||
$env:COGNITIVE_AGENT_VEHICLE_CAN_ENABLED = "true"
|
||
$env:COGNITIVE_AGENT_SEAT_CAN_BACKEND = "zlgcan"
|
||
$env:COGNITIVE_AGENT_VEHICLE_CAN_BACKEND = "zlgcan"
|
||
$env:COGNITIVE_AGENT_SEAT_CAN_CHANNEL = "0"
|
||
$env:COGNITIVE_AGENT_VEHICLE_CAN_CHANNEL = "1"
|
||
$env:COGNITIVE_AGENT_VEHICLE_CAN_ARBITRATION_BITRATE = "500000"
|
||
$env:COGNITIVE_AGENT_VEHICLE_CAN_DATA_BITRATE = "2000000"
|
||
$env:COGNITIVE_AGENT_SEAT_CAN_TERMINATION_ENABLED = "true"
|
||
$env:COGNITIVE_AGENT_VEHICLE_CAN_TERMINATION_ENABLED = "false"
|
||
$env:COGNITIVE_AGENT_SEAT_FIRMWARE_PROFILES = "combined"
|
||
$env:COGNITIVE_AGENT_HARDWARE_APPROVAL_TOKEN = "<bench-only-token>"
|
||
```
|
||
|
||
真实执行会拒绝以下情况：两个逻辑总线配置为同一通道、CAN FD 时序不等于已验证值、ZLG 32 位运行时缺失、座椅固件未通过被动签名检查、车身动作不在可信能力目录内，或需要反馈的车身指令未收到对应状态帧。
|
||
|
||
## 一句话联动示例
|
||
|
||
`副驾座椅通风3档，同时打开空调，温度设为24度，风量3档`
|
||
|
||
该请求生成独立的 `seat` 与 `native_climate` FunctionConfig/CommandPlan。真实执行时，两组执行器在独立线程中使用 CH0/CH1 通道视图；底层桥接仍统一串行化 SDK 调用，并将长时间接收切成不超过 20 ms 的时间片，以便两个通道交替收发。
|
||
|
||
## 验证要求
|
||
|
||
1. 先运行 `zlgcan_bridge.py --self-test`，确认经典 CAN 与 CAN FD API 导出及 ABI 结构尺寸。
|
||
2. 在 ZCANPRO 确认 CH0/CH1 接线、终端电阻和总线状态正常，然后关闭其在线通道，避免与服务争用设备。
|
||
3. 用 dry-run 核对两份计划：座椅报文位于 `seat_can`，车身报文位于 `body_can`；空调控制 ID 为 `0x1DE`。
|
||
4. 以 hardware 模式执行低风险联动句，要求座椅板端反馈成功，且车身通道观测到对应状态反馈（空调为 `0x404`）。仅发送成功而无状态帧不能记为通过。
|
||
5. 验证完成后关闭座椅热舒适功能、发送座椅 `STOP_ALL`，并按测试前状态恢复车身设备。
|
||
|
||
相关机器可读配置位于 `platforms/t2g_cabin_bench/` 与 `config/environments/t2g_cabin_bench.example.yaml`。
|