vee
64 lines
4.0 KiB
Markdown
64 lines
4.0 KiB
Markdown
# T2G 座椅与车身双通道 CAN 联动
|
||
|
||
## 集成基线
|
||
|
||
- 座椅控制沿用当前仓库的 IAR `Seat_Controller_demo` 协议与闭环回读。
|
||
- 车身控制从 `https://git.kendeji.fun/dev-team/project-code` 的 `CAN_DEV` 分支导入，固定基线为提交 `6e7ed04a468dfcde7efda9e30bc15144bf02faf9`。
|
||
- 不允许自然语言直接提供 CAN ID 或原始载荷；只有能力目录中命名、经过范围校验的动作可以编译到车身 CAN。
|
||
|
||
## 适配器和通道
|
||
|
||
一个 `USBCANFD-200U` 只由一个无界面的常驻 CAN Runtime 打开一次。Runtime
|
||
通过 32 位 ZLG DLL 子进程持有设备，再向自编排与自修复暴露两个通道视图：
|
||
|
||
| 通道 | 用途 | 帧格式 | 仲裁速率 | 数据速率 |
|
||
|---|---|---|---:|---:|
|
||
| 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_CAN_RUNTIME_BACKEND = "standalone-zlg"
|
||
$env:COGNITIVE_AGENT_SHARED_CAN_RUNTIME_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 通道视图；两组执行器可以并行，
|
||
底层 Runtime 仍统一串行化单次 SDK 调用。CH0 自修复采用非阻塞接收，避免长期占用
|
||
设备锁；旧的直接执行兼容路径仍把阻塞接收切成不超过 20 ms 的时间片。
|
||
|
||
自修复硬件诊断、四轴归零和六个故障用例同样使用该 Runtime 的 CH0，不再启动
|
||
ZCANPRO。自修复任务与普通座椅任务共享一个队列，因此不会争抢 CH0；CH1 保持同一
|
||
设备所有者并可继续被动接收。固件烧录、设备重启和急停属于设备级维护操作。
|
||
|
||
## 验证要求
|
||
|
||
1. 先运行 `zlgcan_bridge.py --self-test`，确认经典 CAN 与 CAN FD API 导出及 ABI 结构尺寸。
|
||
2. 确认 CH0/CH1 接线、终端电阻和总线状态正常，并保持 ZCANPRO 关闭，避免与 Runtime 争用设备。
|
||
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`。
|